IT Environments – Why Use Microservices?
By Eric Goebelbecker.
New technologies and new ways of doing things are continually impacting the way our IT Environments evolve and how we do things. One area of growing popularity is Microservices.
Why Use Microservices?
Why should you start using microservices? Why all the hype? Are they only the latest fad, or are there good reasons why so many companies have migrated to them? The fact is, microservices improve many aspects of systems design, build, and environment operation (& underlying automation). We’ll take a look at why microservices are an excellent option for distributed applications. So, if you’re not already familiar with how they can help you create better systems, you’re in the right place.
What are Microservices?
Microservice architecture breaks applications down into collections of small services. Each service is designed to address a specific business capability. Then, designers address technical concerns only after they choose the service’s role. So, an excellent example of a service’s area of concern is “customer information”. A poor one would be “relational database access”. This distinction is an important factor in why microservices are so successful, as we’ll see below.
A monolithic service has libraries built around technical or business capabilities. You may link third-party API libraries into the application. Or, you might use “plug-ins” that make it easier to add new behavior. Microservices use a radically different approach. Developers add new abilities by creating new services that run in a new process. The monolithic service runs in a single process, so it can be more complicated to manage and upgrade.
Microservices separate each business concern into a discrete service. The libraries and APIs used in the process are those needed to fulfill its business concerns. The service communicates directly with clients. It uses a lightweight protocol, usually a RESTful API delivered over HTTP. Microservice systems generally need little central management.
So, what makes component systems better than monolithic ones?
The Single Responsibility Principle Writ Large
The single responsibility principle is a guideline for designing software. It states that software modules or classes should have responsibility for only one thing. A well-written application or library consists of components that enjoy solid boundaries. Robert C. Martin defines the principle this way.
The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.
That single “reason to change” is a crucial part of Martin’s definition. When you map a software component to a distinct business concern, it responds better to business requirements. The principle also protects it from conflicting or unrelated dependencies that can distort its purpose.
When you write a software module, you want to make sure that when changes are requested, those changes can only originate from a single person, or rather, a single tightly coupled group of people representing a single narrowly defined business function. (emphasis added) You want to isolate your modules from the complexities of the organization as a whole, and design your systems such that each module is responsible (responds to) the needs of just that one business function.
This principle is a crucial reason why microservices are a good architectural strategy. A well-designed microservice only has one reason to change. So, new requirements cause minimal disruptions since areas concern are well-defined. A system made of loosely-coupled services can adapt to changing business requirements.
Divide and Conquer
When you break an application down into services, you can divide your development up too. Each team takes an area of concern and focuses on delivering an application that fulfills it. This ability to create parallel development teams isn’t a coincidental side effect of microservices. It’s a key benefit of component architecture that helped drive its popularity. Microservices make both technology and business teams happy, so it’s no surprise that both large and small companies have embraced it.
Monolithic architectures need centralized management and standardized tooling. Even if you can break the development effort down into individual teams, they’re still working on the same application. Any change requires a complete release cycle of the service. If you need to make more than one change, you have to combine them into a single release. Or, you have to queue releases one after the other and make stakeholders wait.
Microservices avoid these conflicts and require almost no centralized governance. Development teams can work on individual schedules. They can release their services on their own schedules too. Rather than trying to coordinate the efforts of several groups, management can focus on results.
The individual development teams can also select the tools and infrastructure they need. A monolithic application often means a development monoculture. Not so with microservices. Teams can choose the best tool for the job. This can mean different languages, database platforms, or storage technologies.
Many technologists think of microservices and agile as going together. There’s a good reason for that. Short development cycles that create tight feedback loops are at the heart of agile. Microservice architectures are the perfect environment for agile since they can deploy new code faster and more often.
Slow and complicated release cycles plague monolithic architectures. First, every change risks triggering a conflict. Does it need a full regression test, or do we risk skipping it? Second, you can only schedule deployments on weekends or during tight release windows. These factors combine to slow releases down to every few weeks at best, often even less frequently.
A microservice architecture is more compatible with agile methodology. Releases are easier since they are, in every way, smaller in scope. Only one service needs a QA cycle. You just need to deploy the single service. You have more freedom about when you deploy since the process is smaller in scope and represents less risk. So, you can release more often. Development receives timely feedback, and the system is responsive to changing requirements.
How do you scale a monolithic service? Usually, it involves adding load-balancing so more than one server shares the traffic. Or you can go with that most-revered of solutions, “throw more hardware at it.” You buy a bigger server with more memory and faster storage. If those approaches aren’t available or don’t work, you’ve got a problem. But happens when those solutions don’t work? What if the problem lies inside the service? It’s back to the drawing board.
Microservices, tend to be easier to scale. It’s easier to identify bottlenecks in a collection of small services. So, even if you do have to result to throwing hardware at the problem, you can throw at the single service that needs it. If the service needs redesigning or replacing, the team responsible can do the job without disrupting the rest of the system.
Also, as more and more enterprises embrace the cloud, containerization has risen in popularity. Microservices lend themselves to containerization since they are small applications with a limited set of dependencies. So, you can quickly scale your services horizontally with technologies like Docker and Kubernetes without writing any additional code.
Solving Design Issues with Focus and Agility
Microservices solve problems by applying time-tested software design principles at the system level. There are many benefits to this approach. First, the system tends to focus on business problems first, and technical concerns second. Second, the applicants adapt to new requirements quickly, making developers and stakeholders both happy. Finally, microservice-based systems are easy to deploy to clouds and scale well.
This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!)
20 MAY, 2019 by Mark Henke It’s a great step when teams deliberately manage their deployments instead of treating them as second-class citizens to writing code. But there are many pitfalls to managing deployments effectively. Many things lurk, waiting to trip us up....
08 MAY, 2019 by Mark Henke Taking enterprise release management seriously is a great step toward helping our organization flourish. Embracing release management will allow us to make the invisible visible. We’ll be able to effectively manage how work flows through our...
04 MAY, 2019 by Rodney Smith If you work in an organization that uses the scaled agile framework (SAFe), chances are it's not a small company. It's enterprise-y. It's probably gone through some growing pains, which is a good problem to have in the business sense. The...
29 APRIL, 2019 by Carlos "Kami" Maldonado "DevOps at scale" is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was coined almost 10 years ago, even in 2018 most organizations still haven't completely...
24 APRIL, 2019 by Mark Robinson It’s the normal case with software buzzwords that people focus so much on what something is that they forget what it is not. DevOps is no exception. To truly embrace DevOps and cherish what it is, it’s important to comprehend what it...
16 April, 2019 by Eric Goebelbecker Your organization is in the midst of an agile transformation. You know that agile is the way to go, and you're looking forward to, or maybe already reaping, some of the benefits. Who can argue with what agile brings to the table?...