Tips to build a strong

Microservices culture

Sundaresan Krishnaswami
Motivation behind this talk

• Have lived a Monolith to Microservices transformation journey in an e-commerce environment

• Have failed and succeeded with transformation and the migration requirement it brings

• Learnt important lessons in understanding the cultural shift required

• Caution: Will quote a lot from my e-commerce background. Be considerate 

Why Culture

• Microservices are more than source code or containers

• You will work with or in multiple teams

• The transformation must foster innovation

• A mindset change when you move from order to chaos

Communication

Any organization that designs a system

(defined broadly) will produce a design
whose structure is a copy of the
organization's communication structure..
-Conway’s Law
Communication

• Services are decoupled, decomposed and disintegrated

• Initially smaller set of services to a large set over a period of time

• Smaller services enhances maintainability

• Autonomy within teams

• Fosters individualistic thinking

• Challenges start from here

Communication cont’d…

• Services interact with each other

• For customers it is a single unit to complete a job

• Teams must interact too

• Success depends on how modules interface correctly

• Dependency on ‘Your’ microservice

• ‘Your’ design or re-design affects others

• ‘You’ alter test data in an environment affecting testing across teams

Communication cont’d…

• Restricted team size

• Teams sign-up to a greater goal, but maintain independence

• Contract meetings between teams and within stakeholders

• Document everything

• Create a ‘syslog’ for each team – for everyone to see

Communication cont’d…

• Implement Swagger (if not already) for each service

• Implement contract tests

• Any API change should follow through with JIRA tickets across independent teams

• Penalties for contract violations

• Maintain and document test data used for others to see

Technology

Every once in a while, a new technology, an

old problem, and a big idea turn into an
innovation

-Dean Kamen
Technology

• Freedom to choose technology

• Loose structure, decoupled components

• Challenges it brings:

• Each team following its own strategy to decompose

• Standardization in architecture

• Services may not be close to each other

Technology cont’d…

• Size matters – Smaller codebase is better

• Polyglot architecture only when options are less

• Avoids maintenance overheads

• Avoid creating Monolithic hell in a Microservice 

• Instead implement API gateway

• Make sure one service does one thing well

Technology cont’d…

• Make way for input from another service

• Build afresh where necessary

• You are truly a microservice if you follow this Rule of Thumb: ‘New developer should understand your code in 1-2 days’

• Enable caching for better inter-app communication

• Most important have a provision to evict cache

• It is never an unforgivable sin – always adapt to change

• Avoid too many back and forth communication between services

Tools and Process

“Just like with everything else, tools won’t give

you good results unless you know how, when,
and why to apply them. If you go out and you
buy the most expensive frying pan on the
market it’s still not going to make you a good
chef”
-Christin Wiedemann
Process

• Services interact with each other

• Teams must interact too

• Success depends on how modules interface correctly

Process cont’d…

• The need for release management to go across services

• Get the specification right

• Sprint grooming from the word ‘go’

• From a product Spec to production ‘standardization’ will be the need of the hour (BDD)
Dev/TestOps - Automation

The first rule of any technology used in a

business is that automation applied to an
efficient operation will magnify the efficiency.
The second is that automation applied to an
inefficient operation will magnify the
inefficiency.
-Bill Gates
Dev/TestOps

• True benefits of Microservices can be achieved using automation

• Deploy, monitor and scale hundreds of services over a period of time

• Challenges:

• Multiple environments

• Repository and managing artifacts

• Configuration management for better service discoverability

Dev/TestOps cont’d…

DevOps

• Configuration Management

• Shared database management for testability

• Shared third party configuration

• Work out a dependency tree before each major release

• Have discussions around dependency tree whenever it is required

• Fault tolerance when services go down

• Roll-back strategy

• Logging and monitoring

Dev/TestOps cont’d…

TestOps

• Test Automation for compliance – No-No

• Spend your automation effort based the test pyramid – Unix – Service – UI layer

• Be prepared for migration nightmare 

• Test data management across environments, shared databases

Performance

If an end user perceives bad performance

from your website, her next click will likely
be on your-competition.com

-Ian Molyneaux
Performance

• One service’s output could be the other service’s input

• Impacts Performance

• Could expose component level response risks

• Messaging services could go down as well

• You test customer impatience

Performance cont’d…

• Each service has to be performance tested from a usage perspective

• Prepare integration scenarios

• It is not only APIs, messaging queues take the load as well – test it

• Capacity planning is a must for every service that is onboarded

Summary
• Understand what does a Microservice culture mean to your company?
• Are we targeting release speed?

• Reduce cost?

• Improve Resilience?

• Improve customer base?

• It starts from you – Don’t be the good guy, question everything

• Embrace - build, automate and operate approach
• Fail fast