Architecting a More Modern System

A Look at Microservices

Making the move from one monolithic service to many microservices can be a complicated process. Here are some reasons why we decided to make the move anyway.

The Problem

We have a need for external businesses to be able to embed parts of our apps into their front ends, connect with our APIs, and not bother the third parties with implementation or data handling details. We also don't want to have to maintain too many different solutions and technologies, so if possible the solution should overlap with our own internal needs.

The Solution

Microservice architecture to the rescue, but what really does that mean besides being a marketing buzzword? I'm going to cover three core ideas of microservices: decoupling, distribution, and technology agnosticism.

Decoupling

The obvious result of turning one application or service into many is that the resulting services are less tightly tied together. For people who aren't developers, it might not be obvious why services that are less reliant on each other might be better than the alternative.

As in all things, programmers deal with side effects of their actions, or more precisely, the actions of their code. Without getting into too many details, programming side effects can be nasty. There are a whole host of frameworks, technologies, and design patterns that are specifically built to avoid unwanted side effects. Microservice architecture isn't built with that sole goal in mind but it does help us mitigate side effects by requiring our service to have well-defined interfaces for interacting with other services. Basically, when turning one application into many that act as one, we need to take the time to define how they talk to each other including any security and permissions that exist as part of those interactions. We now have a single point of failure for these interactions. It also means that one service can't accidentally do something with another service that it's not supposed to. It's much easier to test our services' internal logic, test their interactions with other services, and even test adding new external services before they even exist. Decoupling leads to more secure, predictable, testable, and fault-tolerant systems.

Distribution

When I talk about distribution here, I'm talking about things like the ability to distribute computation across separate hardware resources, but I'm also talking about things like continuous integration pipelines (integration, delivery, and deployment), integration with third parties, and scalability.

Taking this from a development timeline standpoint, we begin with continuous pipelines. Continuous integration is the ability of developers to frequently and easily integrate changes into the app. Continuous Delivery and Deployment are similar to each other. Delivery is the automation of our ability to deploy an application at the click of a button. Deployment takes delivery one step further and automates the deployment when a change is integrated and passes the integration tests. The main difference is that continuous delivery still needs a person to say "go ahead and actually deploy" whereas continuous deployment is only stopped if tests fail. Because our microservice is decoupled and easier to test, it's much easier for developers to integrate changes into the service. It's also possible to use external CI pipeline tools, like Jenkins, Travis, and GitLab CI that can hook into our applications and automate this integration and deployment processes.

Moving to the next step in our distribution process, turning our single giant app into smaller ones makes third-party integration easier. Like CI pipelines, third-party integration is simple in a microservice platform because of the decoupled nature of the services. The testability and security that isolating the services provide let us pick and choose who gets access to what and how they interact with the things they have access to. Also, by having tight control over the development and deployment process with CI pipelines, we can have the confidence to offer more services to external parties without worrying about unmanageable support costs.

The last bit of distribution that's more effective in our new architecture is the ability to scale. This is a major win for the design pattern and might actually be one of the initial reasons people started looking into this way of doing things. When our applications are independent and technologically agnostic, we can pick the best platforms and technologies to run them. When everything has to have a well-defined API for talking with everything else, it's easier to move our apps around and put them where it makes the most sense. It used to be the case that most of a company's code would live on the same network in an in-house server room, but now it's not uncommon to have on-premises hardware talking to cloud servers talking to any number of other companies' servers and so on. Since we're already building all of this into our applications, it's simple to add more resources to our service platform.

Technology Agnosticism

Saving my favorite for last, technology agnosticism is probably the biggest strength of the microservice architecture design pattern. What this means is that there's nothing stopping us from using the best tool for each job. With a monolithic application, we need to pick one tool or small set of tools that work well together and use it for everything. It doesn't take much explanation to see how these highly specialized apps run faster and are easier to maintain. Not only are there real benefits like efficiency and performance, but there's an intangible benefit as well. I get much more job satisfaction out of being able to work on a group of different things rather than plugging away on the exact same code every day. It helps me grow as a developer and it also keeps my mind open to new approaches to solving problems. As the old saying goes, if you only have a hammer, everything starts to look like a nail.

Bringing It All Together

I hope this little primer gave a good rundown of some of the reasons that we're moving to microservices. There are certainly more strengths and weaknesses than I could ever cover in one post, and it's important to consider them all before committing to any design patterns for you or your company. There's a whole world of blogs and articles available on this topic and I'd definitely encourage anyone interested to read more. Not only is it a popular pattern, but it's interesting to read about as well. Any developer worth his salt should have heard of it and at least know when it would make sense to use or not. If you're in marketing or the business side of tech, it's always important to genuinely know what you're talking about. There's nothing more frustrating for a developer than someone who has the authority to come in and ask for buzzwords without really knowing if it makes any sense, but that's a topic for another time.