Virtualization Technology News and Information
Article
RSS
What You Need to Know About Software Architecture to be a DevOps Superhero

By Andrew Whiteside, Biqmind, Software Technical Director

‘DevOps engineer' ranks highly on many Top Ten Tech Jobs of 2020 lists. But what actually makes a great DevOps engineer? The scope of the actual role varies from organization to organization. In smaller start-ups, the DevOps engineer might work very closely with the software development team to ensure delivery. In larger organizations, they tend to focus on optimizing infrastructure.   

DevOps is the fusing of software development and operations, breaking down the silos so that we can develop and maintain software which can be released faster and with less issues, it is a total culture shift from traditional software development. From that perspective, for a DevOps engineer to really influence and impact the way things are being done, they need a broad spectrum of knowledge, from infrastructure at one end, software development in the middle and software architecture at the other end. 

However, as a hiring manager, many candidates I interview tend to come from infrastructure and operations backgrounds. The result, in my opinion, is a lot of DevOps engineers do not fully understand how software architecture impacts container-based operations.

Software architecture is important for everyone on the project or team, not just the architects or engineers. It provides a clear baseline of where your application is currently, and a broad general direction of where the application needs to be.

Software architecture is not meant to be drawn on stone tablets by some architectural god, high up on a mountain and then passed down to developers who leave it to gather dust in a lonely drawer - it should be a living artefact that is constantly referenced and continually evolving.

Your software architecture should clearly spell out which architectural "ilities" are priorities for your application - scalability, availability, extensibility, security, portability etc. Not enough project teams, including teams I have been on, run reviews of the current application architecture with a view on how to progress it in the future.

This article is meant to help DevOps Engineers better collaborate with and influence the larger software team organization by providing a quick primer on core container-based architecture principles.

CONSIDERATIONS FOR A CONTAINER-BASED ARCHITECTURE

Moving to a container-based architecture is an increasingly popular trend as part of the broader application modernization topic. Key benefits include speed, consistency, scalability and affordability. You could reap some of these advantages immediately just by moving to a container environment. But for most applications, it requires modifying the architecture to get the most out of what containers promise.  

When is a container architecture viable? Some starting points where a container architecture is worth considering:

  • Existing working MVP with feedback from real users
  • Established application that is growing and needs to scale
  • You are looking to reduce running cost
  • An application has become unmanageable

PATTERNS FOR CONTAINERIZATION

Now assuming you are a DevOps engineer, proficient in working with Kubernetes and someone says "Hey, we've got this application, make it into containers", there are a few options open to you, each requiring differing degrees of collaboration with the development and architecture teams. There is no standard pattern to follow, it really depends on project or organizational needs. Here are a few you could follow:

"Lift-&-Shift"

"Lift-&-Shift" is a good place to start when you need to quickly move an application into containers. You simply take the application and dump it wholesale into a container. The application is now "containerized" but has not been redesigned and would be difficult to scale in its current state.

Tiered Separation

Another approach you could take is tiered separation in containers. For example, if you have an application consisting of different tiers: a react web application, a service tier and data. Assuming the tiers are not tightly coupled, you could separate the application into three containers; the first containing the react web application, the second container containing the service tier with Java backend APIs and the third containing your data tier. With this approach, the application is potentially scalable.

Logical Separation

Another option is to logically separate the application. For example, an e-commerce application could be logically separated into ordering services and customer databases with a service bus enabling communication between the services. Separating an application this way would ease deployments as you could deploy each service individually, resulting in a higher availability of the application as a whole. With this approach, the ordering services could scale out to meet the additional demand during a sale or promotion and scale down afterwards, all without affecting the other services.

Both Tiered and Logistical Separation need a thorough understanding of the software architecture to successfully implement and scale i.e. the DevOps engineer has to collaborate deeply with the development and architecture teams to make it happen.  

KEY CONTAINER ARCHITECTURAL CONCEPTS

Stateful & Stateless

You will definitely hear people talking about Stateful and Stateless services, mostly in the context that Stateful services are harder to scale than Stateless services. Stateful services store and rely on data for their state, for example, a customer record keeping service which keeps data or a shopping cart service, which holds the current user's cart choices. Applications that use Stateful services tend to be harder to scale due to potential duplication of data which could result in syncing issues. On the other hand, Stateless services do not rely on data and work more like functions, for example, a music recommendation engine or an image processing service. These are easier to scale precisely because they do not store data.

Tight Vs Loose Coupling

The next concept is tight and loose coupling, this comes from programming. We talk about classes, objects, services being tightly coupled together i.e. dependent on each other. Loose coupling is when they are not dependent on each other and can be deployed without each other. The key thing to note is tightly coupled services are difficult to deploy and often limited by the slowest component.

Data Design

With microservices, you want to design the architecture in such a way that you have independent and separate data sets per service, this is difficult to do but critical to scaling. You need to consider where data is to be stored, which component needs to reference the data and how the data will be referenced. The latter could be done through APIs or more evolved methods such as Command Query Response segregation (CQRs) where each secondary service keeps an updated read only copy of the data required.

Disposability

Containers are by design, highly disposable, they can be scaled up and down very quickly and cleanly. As you move applications into containers, your services need to embrace and be designed for disposability, you don't want to shut down containers which still have hooks to your databases and files - that would be a disaster for your applications.

HUNT RABBITS NOT GRIZZLIES

If you are a DevOps Engineer just starting out, what should you focus on to make an impact? In answer to this, a hunting analogy comes to mind. If you are taking up hunting, you would probably start out hunting rabbits first and not immediately try to tackle grizzlies. In the same way, start small, pick off bits and work from there, rather than trying to tackle a grizzly bear, because bad things can happen.

  • CD & Automation
    Automate as much as you can. When you set up your CI/CD pipelines, do it based on the existing team structure and processes and evolve from there.
  • Greenfield first
    If you are moving your applications into containers, you need to find your ideal candidate. Ideally, start with a greenfield project and move that first.
  • Stateless before stateful
    If you've got only Brownfield products or projects that you're working with, prioritize and move the stateless services first into container environments.

I have covered some key architectural considerations, patterns and concepts, which I hope provide food for thought and get you thinking about the importance of architecture in relation to becoming a DevOps Superhero. Some bedtime reading material I would highly recommend are two software architecture classics: Domain Driven Design and Building Evolutionary Architectures. Good luck!

##

***To learn more about containerized infrastructure and cloud native technologies, consider joining us at KubeCon + CloudNativeCon NA Virtual, November 17-20.

About the Author

Andrew Whiteside, Biqmind Software Technical Director

Andrew Whiteside 

Andrew has 15+ years of experience in software development / management /architecture. He understands the pains of development teams first-hand, and is able to provide a practical perspective on how to support teams in transitioning to new tools, technologies and approaches. He is a subject matter expert on areas such as Test Driven Development, Pair Programming, Scrum, Kanban, DevOps, CI/CD, Domain Driven Design and Evolutionary Architectures among others.

Published Friday, October 30, 2020 7:41 AM by David Marshall
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<October 2020>
SuMoTuWeThFrSa
27282930123
45678910
11121314151617
18192021222324
25262728293031
1234567