Microservices Anti-patterns

What it Was, Was Microservices

Buzzwords often give context to concepts that evolved and needed a good tag
to facilitate dialogue. Microservices is a new tag that defines areas I have
personally been discovering and using for some time now. Articles and
conferences described something that I slowly realized I had been evolving in my
own personal experience for the past few years. While industry and professional
discussions on Microservices have given the limelight to the companies like
Netflix, Amazon, and Google and to the practitioners who have done it
successfully, I have some personal experience that can provide insight to
successful Microservices implementation.
The three standard and most common business drivers for any architecture are:
>Improved Agility The ability to respond to the business needs in a timely
fashion so that the business can grow
>Improved Customer Experience Improve the customer experience so that
customer churn is reduced
>Decreased Cost reduce the cost to add more products, customers or business
solutions
In fact, all of us are trying to do this in our day-to-day work. SOA creates a
business aligned software framework that enables the enterprise to get there.
Several large software vendors have emerged and claimed that their suite of
products can enable the enterprise to deliver SOA.
If you do not have the right people, culture, and investment, SOA will not deliver
the business value. Microservices architecture is not fundamentally different
from SOA, the goals and objectives are the same but the approach is slightly
refined and in fact, I would simply say that Microservices is mere SOA made
scalable. Microservices enables applications/systems that desperately must
move away from a monolithic implementation, to a distributed, decentralized,
services platform serving many applications. Microservices are independent that
embrace agility and application evolution as an enterprise digitally transform.
Microservices success depends upon the service independence and the service
flexibility.
I would define Microservices as An approach to delivering SOA by building finegrained services to support business capabilities that are distributed and
organized as functional domains". No pattern is a magic wand or silver bullet. You
should conceive and tailor the pattern correctly for an enterprise. Enterprises
should focus on resolving the items that are required to support the architecture
to make an adaptive platform.
A few enterprises failed in their SOA implementation miserably because they
did not fully analyze their business capability model and considered developing

web-services mean SOA or buying a SOA suite from large vendor would make
them SOA-enabled or the inability to show the alignment between SOA and their
business driver/goals.
For Example
An example from experience might clarify this point. At one past job, the
enterprise was aiming to improve agility, customer experience and drive down
cost. We decided to build a standard multi-tenant SOA platform. The approach
was set to develop fine-grained services so that we could make changes very
often and deploy small, manageable changes to the platform. If we did the same
approach today, we would likely call it microservices architecture. Back then we
did not have this term, but it just made sense.
Services were modeled based on business capability model and the first release
went well. They were XML over JMS sync services and primarily focused on
delivering the capabilities required for claims platform exposed to Agents, web
and voice channel application. It gave us the ability to deploy frequent, small
changes and A/B feature support seamlessly for our applications.
When the requirements were incrementally added (and they always were) it was
very hard to release the solution rapidly because of the integration complexity
between applications and the consumers. Integration, functional testing, and
production release required tight coordination. As the business started to expand
and the changes were 10x more frequent than the initial release, and as most of
the tasks in delivery lifecycle were manual, the time to market did not meet
business expectation. Soon, none of our goals were met as poor Microservices
automation and lifecycle management led to delivery entropy.
Lessons Learned Dont Do These Things, InsteadDo These OTHER Things
This brings me to share some of the lessons that I learned as part of my journey
so that you can keep an eye on these items when you hit the road with
Microservices
1) Cohesion Chaos
We developed a service to get the customer information designed to pull the
customer policy information, personal information and the plan that they enrolled
in. Over a time, it started to do more than getting the customer information. As
new requirements came in, this service went through frequent changes and
deployments. It was unable to scale and meet the required availability. It became
the proverbial Big ball of mud. How did it get there? For starters, there was no
governance around functional separation of concern. If an influential consumer
asking to put unrelated logic in this one service to reduce round trips, that
function got slapped on without question. Perhaps a gateway or a BPM layer
could have avoided this scenario, but there was no time for thatjust time to
crank out another business function point.

The preventative cure is to govern business functionalities that are not relevant
to the service. Services must align clearly to a business capability and should not
try to do something outside of their boundary. Functional separation of concern is
vital for architecture to govern otherwise it will destroy the agility, performance,
and scalability and ended up in establishing a tightly coupled architecture,
resulting in delivery entropy and cohesion chaos.
2) Not taking Automation Seriously
We didn't have a strategy for automated deployment and ops monitoring of
services (runtime QoS metrics). It obviously increased operational expenses and
manual errors during deployment. Several times production deployments caused
outages due to configuration errors. The services were always deployed in HA
mode and so the number of containers was 3x to the total number of services.
The operations team was unable to handle the configuration for each service
manually. After a certain time, ops started to complain that the architecture was
inefficient as they were not able to handle the increased number of containers.
What is the vaccine for this? The recipe has multiple ingredients. Continuous
deployment, if you have not done so, is a must investment and a cultural change
that every enterprise should aim for. At least, if you don't have a way to
automatically test and deploy do not do micro-services. Microservices are
aiming to drive agility, with the speed we need to change; quality assurance
involves each service having automated unit, functional, security and
performance testing. Service Virtualization is another powerful concept when we
develop services that are integrated with services outside of our control.
3) Layered Services Architecture
One common mistake people made with SOA were misunderstanding how to
achieve the re-usability of services. Teams mostly focused on technical cohesion
rather than functional regarding reusability. For example, several services
functioned as a data access layer (ORM) to expose tables as services; they
thought it would be highly reusable. This created an artificial physical layer
managed by a horizontal team, which caused delivery dependency. Any service
created should be highly autonomous meaning independent of each other.
Creating multiple, technical, physical layers of services would only cause delivery
complexity and runtime inefficiency. We ended up in having wrapper services,
orchestration services, business services and data services. These service
models served technical concerns. Individual teams formed to manage these
layers and ended up having business logic sprawl, no single owner for a
capability, lost the efficiency and there was always a blaming game.
Logical separation of layers within a service is fine, however, there should not be
any out of process calls. Try to look at a service as one atomic business entity,
which must implement everything to achieve the desired business functionality.
The self-contained services are more autonomous and scalable than the layered
services. It's perfect to re-write some common code across multiple services,

that's fine and it's a good trade-off to keep the autonomy level. The bottom line
is that don't have services separated by technical concerns instead they must be
separated based on the business capability. The concept of containerization is
thriving because of this character.
4) Relying on Consumer Sign-off
We had a service consumed by multiple applications from three different
channels i.e. agent, the web, and voice. Agent channel was our primary, so the
services had to wait to get their sign-off before they can go into production. It
delayed the voice and web application production releases. What bound those
three channels together so tightly?

The service was not a loosely coupled when it came to channel specific
functionality. Give independence to your services. Every service that you deliver
must have a test suite, which should cover all the service functionality, security,
performance, error handling, and consumption driven testing for every current
and future consumer. This must be included as part of the build pipeline for
automated regression testing.
5) Manual Configurations Management:
As we started to do a larger number of services (and the inevitable sprawl due to
lack of service lifecycle governance manifested itself) managing the
configurations for each service went out of control. Most of our production
deployment was not smooth because of configuration failures like the bad
password, wrong URL, incorrect values. It became harder and harder to manage
these manually. If we had only used application configuration management tools
as part of a PaaS or CDbut we didnt.
6) Versioning Avoidance:
Naively, we thought it would be only need one version of the service. Then we
started to add major, minor versions to accommodate multiple consumers and
frequent changes. Eventually, every release had to be a major release since the
services were relying on consumer sign off. As a result, the number of containers
increased very fast and it became a huge pain to manage them. Lack of runtime
governance was another aspect that contributed to this issue. Some enterprises
foolishly try to avoid versioning. Services need to be architected assuming that
change is inevitable. Have a strategy to manage the forward compatible service
changes and allow your consumers to upgrade gracefully. Otherwise, it will lead
to having consumers tightly bound to a service version and break when there is a
change.
The complexity grows as the number of services grows which the microservices
world expects. Have a versioning strategy that can allow the consumers a
graceful migration and assure providers can transparently deploy changes

without affecting anyone. Limit the number of side-by-side major versions in the
production and govern them.
7) Building a gateway in every service
We didn't have an API gateway and we didn't have runtime governance (we
didnt know who was consuming what and at what rate at what time). We started
to implement end-user authentication, throttle, orchestrate, transform, and route
etc. in each service. It added complexity to each service and we lost consistency
of implementation from service to service, so we had no idea who implemented
what and where. On top of it, some of our services were built to satisfy one
consumer non-functional requirements, but not anothers. If we had a gateway,
applying some data filtering and enrichment patterns could have done it. If only.
Invest in API Management solutions to centralize, manage and monitor some of
the non-functional concerns and which would also eliminate the burden of
consumer's managing several microservices configurations. API gateway can be
used orchestrate the cross-functional microservices that may reduce round trips
for web applications.
Conclusion
The goal of microservices is to solve the three most common problems i.e.
improve customer experience, highly agile to the new requirements and drive
down cost by delivering the business functions as fine grained services. This is
not a silver bullet and requires a disciplined platform, where delivering the
services in an agile fashion with high quality is possible. Learn from others
mistakes (mine) and avoid the above listed patterns in the architecture and
delivery process. This is the first baby step before we can even talk about
containerization, cloud adoption etc. I hope this article gives you something to
think about for your enterprise and work towards resolving these anti-patterns
before you weave them into your architectures. Most of the items will drive
cultural changes within the organization and cannot be done just by yourself,
ensure partnership with your executive and senior leaders.
Source : infoq.com
Recommended by :
Jon Cohn ,CTO , VP IT Architecture
https://www.linkedin.com/in/jonacohn
joncohn@comcast.net

"Jon Cohn Exton PA" "Jon Cohn Exton" "Jon Cohn Evolution"

https://docs.google.com/document/d/1jhU5Mis7YoGzJvK85coGd8yZIHs-JnCG_cyz-p_y9Jk/edit?

usp=sharing
http://issuu.com/jonacohn/docs/jon.cohn.resume.docx
https://www.scribd.com/doc/294344968/Jon-cohn-Resume
http://www.slideshare.net/jonacohn/joncohnresume
https://penzu.com/p/e1f1fb23
http://jonacohn.tumblr.com/post/136671484928/jon-a-cohn
https://jonacohn.wordpress.com/2016/01/06/jon-a-cohn/
http://jonacohn.blogspot.com/2016/01/jon-cohn-resume.html

www.slideserve.com/jonacohn/jon-a-cohn-exton-pa
http://www.authorstream.com/Presentation/jonacohn-2711402-jon-cohn-exton-pa-19341/
www.slideserve.com/jonacohn/jon-a-cohn-exton-pa
http://slideonline.com/presentation/99077-jon-a-cohn-exton-pa

https://docs.google.com/document/d/1NJujdCMyQTF9qReGp6oMbmvWBXWEqPu1avWwEMAgmo/edit?usp=sharing
https://plus.google.com/105089455909133040148/posts/1j3SQfwm6QW
http://jonacohn.blogspot.com/2016/01/knowledge-management-in-software.html
http://docslide.net/technology/knowledge-management-in-software-architecture-.html
http://issuu.com/jonacohn/docs/knowledge_management_in_software_ar
https://www.scribd.com/doc/294345138/Knowledge-Management-in-Software-Architecture
http://www.slideshare.net/jonacohn/knowledge-management-in-software-architecture
https://penzu.com/p/20142217
http://jonacohn.tumblr.com/post/136671606138/knowledge-management-in-software-architecture
https://jonacohn.wordpress.com/2016/01/06/knowledge-management-in-software-architecturestate-of-the-art/
https://docs.google.com/document/d/1CfsHdjb2TmLzBqgUu5bqTolxNJIJdYyj4WKvYs9Isqc/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/RQtZGoR4qEd
http://jonacohn.blogspot.com/2016/01/microservice-architecture-patterns-and.html
http://docslide.net/technology/microservice-architecture-patterns-and-best-practices-.html
http://issuu.com/jonacohn/docs/microservice_architecture_patterns_
https://www.scribd.com/doc/294345139/Microservice-Architecture-Patterns-and-Best-Practices
http://www.slideshare.net/jonacohn/microservice-architecture-patterns-and-best-practices
https://penzu.com/p/4a54eb47
http://jonacohn.tumblr.com/post/136671688403/microservice-architecture-patterns-and-best
https://jonacohn.wordpress.com/2016/01/06/microservice-architecture-patterns-and-best-practices/
https://docs.google.com/document/d/16a4js8-8Aun-getG1O1J5G2LfCOsiv6nvWfAJDL0itI/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/AR8bEGBYukJ
http://jonacohn.blogspot.com/2016/01/microservices-anti-patterns.html
http://docslide.net/technology/microservices-anti-.html
http://issuu.com/jonacohn/docs/microservices_anti.docx
https://www.scribd.com/doc/294345141/Microservices-Anti
http://www.slideshare.net/jonacohn/microservices-anti
https://penzu.com/p/fb7180ed
http://jonacohn.tumblr.com/post/136671725568/microservices-anti-patterns
https://jonacohn.wordpress.com/2016/01/06/microservices-anti-patterns/

https://docs.google.com/document/d/1yW3qK63RbReFDM0u7QaFaN6GQ7aztbovav7eKbKaUyg/e
dit?usp=sharing
https://plus.google.com/105089455909133040148/posts/JoonTaUmWJN
http://jonacohn.blogspot.com/2016/01/software-architecture-antipatterns.html
http://docslide.net/technology/software-architecture-antipatterns-.html
http://issuu.com/jonacohn/docs/software_architecture_antipatterns.
https://www.scribd.com/doc/294345142/Software-Architecture-AntiPatterns
http://www.slideshare.net/jonacohn/software-architecture-anti-patterns
https://penzu.com/p/623a155f
http://jonacohn.tumblr.com/post/136671788668/software-architecture-antipatterns
https://jonacohn.wordpress.com/2016/01/06/software-architecture-antipatterns/
https://docs.google.com/document/d/1amUg47H3WiWfjFyCEXuE2IW0BjsRpy5FcS21ocskPfo/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/3wnZwvKRJVw
http://jonacohn.blogspot.com/2016/01/5-ways-cios-can-rationalize-application.html
http://docslide.net/technology/5-ways-cios-can-rationalize-application-portfolios-.html
http://issuu.com/jonacohn/docs/5_ways_cios_can_rationalize_applica
https://www.scribd.com/doc/294345398/5-Ways-CIOs-Can-Rationalize-Application-Portfolios
http://www.slideshare.net/jonacohn/5-ways-ci-os-can-rationalize-application-portfolios
https://penzu.com/p/59d0714d
http://jonacohn.tumblr.com/post/136671848208/5-ways-cios-can-rationalize-application-portfolios
https://jonacohn.wordpress.com/2016/01/06/5-ways-cios-can-rationalize-application-portfolios/
https://docs.google.com/document/d/1mxok-5UOtBtOrf_DnX-YuJuqWjXz_5dmM6dIWIz42Qo/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/8zoDBqkuVUY
http://jonacohn.blogspot.com/2016/01/8-enterprise-software-predictions.html
http://docslide.net/technology/8-enterprise-software-predictions-.html
http://issuu.com/jonacohn/docs/8_enterprise_software_predictions.d
https://www.scribd.com/doc/294345403/8-Enterprise-Software-Predictions
http://www.slideshare.net/jonacohn/8-enterprise-software-predictions-56574229
https://penzu.com/p/bb8da598
http://jonacohn.tumblr.com/post/136671903488/8-enterprise-software-predictions
https://jonacohn.wordpress.com/2016/01/06/8-enterprise-software-predictions/
https://docs.google.com/document/d/1j6vNIc8UPFBBDwY9Pf3JotXOz2rFFED1_RUiv3uAITA/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/1KzDqVAbsPe
http://jonacohn.blogspot.com/2016/01/9-enterprise-tech-trends-for-2016-and.html
http://docslide.net/technology/9-enterprise-tech-trends-for-2016-and-beyond-.html
http://issuu.com/jonacohn/docs/9_enterprise_tech_trends_for_2016_a
https://www.scribd.com/doc/294345405/9-Enterprise-Tech-Trends-for-2016-and-Beyond
http://www.slideshare.net/jonacohn/9-enterprise-tech-trends-for-2016-and-beyond
https://penzu.com/p/1d693de8
http://jonacohn.tumblr.com/post/136671931568/9-enterprise-tech-trends-for-2016-and-beyond
https://jonacohn.wordpress.com/2016/01/06/9-enterprise-tech-trends-for-2016-and-beyond/
https://docs.google.com/document/d/1MYjcjtP9GbvwW9jCjCHWq6giriccM1DspbFbwX4qyCk/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/iZWpb25woCS
http://jonacohn.blogspot.com/2016/01/best-practices-enterprise-architecture.html
http://docslide.net/technology/best-practices-joncohn202.html
http://issuu.com/jonacohn/docs/best_practices.docx

https://www.scribd.com/doc/294345407/Best-Practices
http://www.slideshare.net/jonacohn/best-practices-56574259
https://penzu.com/p/63e3b811
http://jonacohn.tumblr.com/post/136672044823/best-practices-enterprise-architecture
https://jonacohn.wordpress.com/2016/01/06/best-practices-enterprise-architecture/
https://docs.google.com/document/d/1Wb04CK1FHTJUxRibL74u_YwYf5dxyEqOK5wUgNpcU2g/ed
it?usp=sharing
https://plus.google.com/105089455909133040148/posts/DyvwQzQUnsS
http://jonacohn.blogspot.com/2016/01/enterprise-architecture-innovation.html
http://docslide.net/technology/enterprise-architecture-.html
http://issuu.com/jonacohn/docs/enterprise_architecture.docx
https://www.scribd.com/doc/294345410/Enterprise-Architecture
http://www.slideshare.net/jonacohn/enterprise-architecture-56574277
https://penzu.com/public/c15a5fd5
http://jonacohn.tumblr.com/post/136672100058/enterprise-architecture-innovation-management
https://jonacohn.wordpress.com/2016/01/06/enterprise-architecture-innovation-managementexploring-the-links/
https://docs.google.com/document/d/11ufZjAbBpLn_fnG3q3b1JqVhCRS-K0YxnJAmql1H4W0/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/GgDtXx7nMRs
http://jonacohn.blogspot.com/2016/01/seven-best-practices-for.html
http://docslide.net/technology/seven-best-practices-for-revolutionizing-your-data-.html
http://issuu.com/jonacohn/docs/seven_best_practices_for_revolution
https://www.scribd.com/doc/294345412/Seven-Best-Practices-for-Revolutionizing-Your-Data
http://www.slideshare.net/jonacohn/seven-best-practices-for-revolutionizing-your-data
https://penzu.com/p/ba199cb7
http://jonacohn.tumblr.com/post/136672128658/seven-best-practices-for-revolutionizing-your-data
https://jonacohn.wordpress.com/2016/01/06/seven-best-practices-for-revolutionizing-your-data/
https://docs.google.com/document/d/1t8Q6bRX8mX3mrVczTxlk4rzRJalcYNvNC7d1M-XF3Ao/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/Ku4Fj2SC15z
http://jonacohn.blogspot.com/2016/01/six-steps-to-data-governance-success.html
http://docslide.net/technology/six-steps-to-data-governance-success-.html
http://issuu.com/jonacohn/docs/six_steps_to_data_governance_succes
https://www.scribd.com/doc/294345415/Six-Steps-to-Data-Governance-Success
http://www.slideshare.net/jonacohn/six-steps-to-data-governance-success
https://penzu.com/p/f152cfd5
http://jonacohn.tumblr.com/post/136672450458/six-steps-to-data-governance-success
https://jonacohn.wordpress.com/2016/01/06/six-steps-to-data-governance-success/
https://docs.google.com/document/d/16lyD986BUJSQNRGZ5L_EGaVoj03XP4qCuMYi6lpb1A/edit?usp=sharing
https://plus.google.com/105089455909133040148/posts/h54EfyrsDLh
http://jonacohn.blogspot.com/2016/01/the-big-data-architecture-dilemma-for.html
http://docslide.net/technology/the-big-data-architecture-dilemma-for-cios-.html
http://issuu.com/jonacohn/docs/the_big_data_architecture_dilemma_f
https://www.scribd.com/doc/294345419/The-Big-Data-Architecture-Dilemma-for-CIOs
http://www.slideshare.net/jonacohn/the-big-data-architecture-dilemma-for-ci-os
https://penzu.com/p/427555f6
http://jonacohn.tumblr.com/post/136672497063/the-big-data-architecture-dilemma-for-cios
https://jonacohn.wordpress.com/2016/01/06/the-big-data-architecture-dilemma-for-cios/

https://docs.google.com/document/d/1Dn-1qgitLF-abiZwWE5WAAvaiO7vB-gXWGVIYh8v6ao/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/gxMGKV2uiDn
http://jonacohn.blogspot.com/2016/01/the-next-generation-of-enterprise-it.html
http://docslide.net/technology/the-next-generation-of-enterprise-it-.html
http://issuu.com/jonacohn/docs/the_next_generation_of_enterprise_i
https://www.scribd.com/doc/294345420/The-Next-Generation-of-Enterprise-IT
http://www.slideshare.net/jonacohn/the-next-generation-of-enterprise-it
https://penzu.com/public/c3a53beb
http://jonacohn.tumblr.com/post/136672518848/the-next-generation-of-enterprise-it
https://jonacohn.wordpress.com/2016/01/06/the-next-generation-of-enterprise-it/
https://docs.google.com/document/d/1tXutYHc6npuklzT79T7ZN4Ck6OFgS2zv5gCc5KLW0kI/edit?
usp=sharing
https://plus.google.com/105089455909133040148/posts/XFQccKewNBv
http://jonacohn.blogspot.com/2016/01/where-is-enterprise-architecture-in.html
http://docslide.net/technology/where-is-enterprise-architecture-in-healthcare-.html
http://issuu.com/jonacohn/docs/where_is_enterprise_architecture_in
https://www.scribd.com/doc/294345421/Where-is-Enterprise-Architecture-in-Healthcare
http://www.slideshare.net/jonacohn/where-is-enterprise-architecture-in-healthcare-56574321
https://penzu.com/public/f3710120
http://jonacohn.tumblr.com/post/136672547973/where-is-enterprise-architecture-in-healthcare
https://jonacohn.wordpress.com/2016/01/06/where-is-enterprise-architecture-in-healthcare/