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.
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. Microservices architecture
has been adopted by Amazon, Netflix, Twitter, Uber and PayPal, to name a
about Netflix’s move to the cloud.
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.
If you are considering moving a monolithic application to a microservices architecture, contact us to schedule a 90-minute meeting so we can discuss your business goals.
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. It doesn’t make sense to remove their rooms because
the monolithic house is not easy to change.
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.
Things to Consider for
Microservices to Provide Business Value
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.
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.
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.
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 particular microservice. A microservices architecture,
designed correctly, can be highly configurable without worry of affecting other
parts of the application.
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.
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
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.
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 an any platform such as Windows or Linux. A monolithic
application, once designed for a platform, must stay on that platform unless
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.
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
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
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.
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
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.
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.
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.
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
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
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.
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
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.
Check out a great visual look at common searches people do for microservices architecture! www.answerthepublic.com