The most innovative firms are always seeking new ways to gain an edge on the competition. Increasingly, top companies are deriving business value through microservices architecture. This approach breaks down your application into smaller, modular components that align with business capabilities. This allows development work on the application to directly align with functionality prioritized by business value.
Microservices architecture can be thought of as specialized mini applications that each serve a single business function. They are compartmentalized and self-contained. All domain knowledge necessary for specific tasks resides within a microservice and each microservice has a separate dedicated data store. Communication occurs with other microservices when needed, but they are developed and deployed independently of each other. Companies that are deriving business value through microservices architecture include Amazon, Netflix, Twitter, Uber and PayPal, to name a few.
Microservices architecture doesn’t necessarily dictate the software development process but lends itself well to an agile approach such as Scrum. Designed for continuous integration and continuous deployment (CI/CD), cross functional Scrum development teams are a natural fit for building microservices.
Analogy
Let’s compare a traditional, monolithic application to microservices with an analogy of building a model of a house. The goal is to build the model for an imaginary family of five, consisting of three bedrooms, one bath, a kitchen and a living room.
Approach #1: Monolithic Wood Popsicle Stick House
The wooden popsicle sticks are carefully glued together until the house is complete. The family moves in and it’s exactly as they specified, though a bit crowded when company comes to visit. As the kids become older, they want their own bedrooms. The family must move out during the renovation. In order to be agile, a room is glued on to the side of the house. This solves the addition of a room, but access to the room is through a window, so it’s not acceptable. Again the family must move out while the longer, but correct, implementation of a room addition is architected. The kids grow up and move into their own houses. The rooms are no longer needed, but it doesn’t make sense to remove their rooms because the monolithic house is not easy to change.
Approach #2: Microservices Magic LEGO House
Each room is created as its own independent LEGO structure, a more modular approach. Rooms can be moved around independently without the need to disassemble the house. The house is made with magic LEGOs that allow instant duplication of rooms and removal of rooms as needed. When company comes to visit, the living room and a few bedrooms can be copied to accommodate the higher demand. Room sharing is no longer a problem. When fewer rooms are needed, they are removed automatically. The microservices house is more modular, scalable and agile than the monolithic house.
Consider Your Application
A microservices-based approach isn’t a silver bullet and shouldn’t necessarily be the definite choice for your next project. Microservices is a better fit for some projects vs others.
Good Fits for Deriving Business Value Through Microservices Architecture
- Application needs to be scalable. One of the strong points of a microservices architecture is scalability. Each microservice can be scaled independently. If you need more horsepower for a particular function, you can add it to only the microservice that provides that function. With today’s cloud technologies, computing resources can be increased or decreased automatically as demand changes. This makes the infrastructure that supports your application easier to maintain.
- Changes to production need to be deployed quickly. Microservices can be developed and deployed independently. This allows your development team to focus on small, high value features and deploy them quickly without fear of taking down other parts of the application. With a small set of functionality, microservices are easy to test and are thus more robust.
- Application features are highly configurable. Customers have different needs when using software. It’s common to have configuration built in to meet their needs without deploying separate applications. Because microservices are designed and separated by functionality, it would be easy to toggle a feature on, allowing you to enable and disable a particular microservice. A microservices architecture, designed correctly, can be highly configurable without worry of affecting other parts of the application.
- Software development process supports CI/CD, your business has an SLA with uptime requirements. If your business does not employ an agile methodology which includes CI/CD, then you would not be taking advantage of the full potential of microservices. It’s a very powerful capability to be able to add a small feature or fix a bug quickly without the hassle of a manual process to deploy those changes into production. Deployment of a microservice does not require taking down the unaffected parts of the application. If your company is new to DevOps, or does not have DevOps at all, taking on microservices might be premature.
- Technology strategy is aligned with and driven by business capabilities and priorities. Software development priorities are not always in line with business priorities. At times software projects are technology-driven, rather than emerging from a strong business case. Microservices can (and should) be designed around business capabilities and priorities. A good gut-check is to ask yourself if a business need led you to consider microservices, or if the concept of microservices has you on a scavenger hunt for where you can apply it.
- Development teams are cross-functional. If your business has an agile software development life cycle, then you probably already have cross-functional teams. This means everyone necessary to complete the work is on the same team, as opposed to being separated by specialty. If you don’t have a cross-functional team, a true microservices architecture might be difficult to achieve. Using cross-functional teams to develop microservices allows work to get done without worrying about dependencies on other teams. Your business can then develop, test, deploy, enhance and fix microservices within one team, resulting in greater business agility.
- Programming language and platform independence are important to the business. Microservices can be written in many different program languages. This allows businesses to select the language that best suits their needs and development team’s skills. With containerization, microservices can be deployed on any platform such as Windows or Linux. A monolithic application, once designed for a platform, must stay on that platform unless redesigned.
- Database can benefit from modularity. A benefit of having a microservice have its own data store is that you can change the data schema or even the entire database technology without impacting other microservices. With a monolith, it is much more difficult to change a data store because you have to address all the references to that database or table.
- You are in a quickly changing market where you would benefit from quickly testing innovation hypotheses. Knowing the time to market needs for your business is at the core of the agile vs waterfall evaluation. With waterfall, the development process is linear: detailed specifications, followed by design, coding, testing, rework, then deployment. Sometimes different groups are involved in each of the phases of development. This makes it challenging, if not impossible, to benefit from the agility microservices can provide to your software solutions. With agile, cross-functional teams work on the features with the highest business value in short iterations called sprints. With an agile software development cycle, microservices can be developed, fully tested and deployed in as little as one sprint. This allows your company to be innovative and get necessary market feedback quickly. If a new feature is determined not to be necessary, not a lot of development time has been spent. If the feature is broken, then it can be quickly fixed without impacting the rest of production. If the new feature is valuable, then you can capitalize on the feature immediately.
- Need to be able to satisfy growing customer expectations. Customers are not going to wait around for 6 months or more for features they need or for bugs to be fixed, especially in competitive and fast-changing markets. Microservices inherently allow your company to be more agile due to their independent functionality, allowing for your company to grow or change a product to react to the market without costly cross-cutting redesign.
- Application future growth needs. Knowing the future of the product, or needing flexibility in the architectural expansion / growth might be a good consideration for a microservices architecture. Emergent architecture may be more easily achieved to accommodate a fast-changing market.
Bad Fits for Deriving Business Value Through Microservices Architecture
- Staff does not have microservices experience. If your development team does not have experience or aptitude to learn how to architect microservices correctly, the design could hurt rather than help your application.
- Not in the Cloud. Microservices are designed to take advantage of today’s cloud platform features such as scalability. Businesses still hosting applications in a data center may not be ready for microservices.
- Application doesn’t need to scale. If the application works without the need for scaling now or in the future, then microservices may not be necessary.
- Lack of QA or testing capabilities. All well-written applications require testing, and microservices are no exception. More robust methods of testing and buy-in from the entire development team are required for a properly designed microservices architecture.
Drawbacks
First and foremost, if you do not have a strong business case for realizing the benefits of building with a microservices architecture, you should consider putting it on the back burner. If you have a case for trying it, there are a few drawbacks to consider before making a final decision.
- Added complexity
- Learning curve
- Operational overhead
- Expense
To achieve loosely coupled and highly cohesive microservices, you are adding complexity to your application’s architecture. The microservices themselves and the communication between them must be well thought out. The more microservices your application has, the more complex the application becomes. Done incorrectly, building microservices may not allow you to take advantage of all the benefits they were designed to offer.
Operational overhead increases when switching from a monolithic application to a microservices architecture. It may take time before the benefits of microservices outweigh the operational cost of implementing them. Each microservice requires its own resources, which results in higher costs in cloud platforms that charge based on resources used. There are multiple design patterns for microservices. You will need to make sure the correct pattern is chosen to meet your needs.
Summary: Deriving Business Value Through Microservices Architecture
A microservices approach breaks down your application into smaller, modular components that align with business capabilities. This allows development work on the application to directly align with functionality prioritized by business value.
Good fits for a microservices architecture include applications that require scalability, ease of deployment, uptime requirements and need to react quickly to growing customer needs and changing market conditions.
Bad fits for microservices are applications that do not require scaling or are not backed by the correct technologies/capable people to implement them correctly.
For business where agility translates to value, microservices architecture may be a good choice. However, the decision should not be made lightly, nor for the sake of the technology only. The business needs of the application or product should be the true driver.
While microservices are a great choice to increase responsiveness to customer demands and changing market conditions, do consider the drawbacks and make sure the investment is right for your business.
If you have questions about moving your monolithic application to a microservices architecture, we would be happy to walk you through your best options. Contact us to book a free consultation.
