Vikash Pandey delivered a session on "Microservices – Explored" at ATAGTR2020 ATAGTR2020 was the 5th Edition of Global Testing Retreat. Vikash is an empathetic leader working with people & technology in the area Product Development, Consulting, Support and Operations for 20+ years The video recording of the session is now available on the following link: https://youtu.be/dF5wx4w66s8 To know more about #ATAGTR2020, please visit: https://gtr.agiletestingalliance.org/

1. Microservices 101

2. Agenda
What is microservices
Why should microservices matter to us
Trends supporting Microservices
Advantages, concerns and mitigations
Services and Libraries
Important aspects of
Microservices:
Service discovery and registration
Deployment
Data Handling
Migration strategies of monolith to microservices
Let’s share varying perspectives

3. 43
Married, with a son (12)
Pune, India. Indian citizen
Strengths: Positivity, Maximizer, Developer, Arranger,
Responsibility.
• 20+ years in industry out of that 13+ years with FIS
• Consulting, Delivery, Support
• Result oriented, focused on solving problems
• Technology enthusiast with strong interest in people and their success
• Before FIS:
• Fidelity Investments
• Iflex Solutions
• One Off Software Development
• e-Enable Technologies
• A blogger, a consistent learner, build and share my views
• Advocate of DevOps, Cloud and Microservices
• An Inbox thinker
Who am I?

4. What is microservices
Martin Fowler: an approach to developing a single application
as a suite of small services, each running in its own process and
communicating with lightweight mechanisms, often an HTTP
resource application programming interface (API).
IBM describes it as a cloud-native approach to building applications from "loosely
coupled and independently deployable smaller components, or services" that:
• Have their own stack;
• Use REST APIs and other forms of communication to connect to other
services; and
• Are sorted by business capability and separated into "need-to-know"
chunks via bounded context.
We can summarize it as: microservices are an app design architecture with a philosophy based on building independent
components that all connect via API (HTTP, Thrift or REST) to reduce complexity, increase scalability, and allow applications to
be distributed with more ease than traditional monolithic-style program architecture.

5. Why should microservices matter to us
Few notable concerns
Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT
leaders of organizations with more than 1,000 employees. • The survey also finds significant microservices challenges
that remain are:
• ensuring security (36%),
• integration with legacy applications (32%),
• the complexity of management (31%) and
• updating API documentation (31%).
• Despite these concerns, however, more than 80% of
survey respondents who have adopted microservices
report that their organization performs well against
metrics for development efficiency, the ability to use
new platforms, collaboration across teams and sharing
of services across applications.
• 89% of technology leaders agree that companies that are not able to effectively support
microservices will be less able to compete in the future.
• The primary reasons cited for adopting microservices are
• improvements to security (56%),
• increased development speed (55%),
• increased speed of integrating new technologies (53%),
• improved infrastructure flexibility (53%) and
• improved collaboration across teams (46%)
• Availability (75%), security (74%), performance (65%) and scalability (64%) are given highest
importance.
• Faster development speeds (95%), increased collaboration (94%) and reduced deployment
risks (93%) as key desired outcomes for adopting any new technologies
• The survey also notes 83% of organizations are relying on open-source software to become
more agile. The most commonly used open-source technologies are databases (64%),
containers (48%), API gateways (41%), infrastructure automation (40%), container
orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).
The foundation, to fully utilize the capabilities of microservices, is to have a strong DevOps culture embedded in the team.

6. Trends supporting Microservices
• In 2019, trends that were prominent and pervasive:
• Test Automation, the result of test-driven development that requires developers to carry out tests throughout the Continuous Integration (CI)
pipeline.
• Incident Response, rise of Site Reliability Engineers is a response to the resiliency challenges of the systems. They were and are in charge of
efficiency, performance, latency, availability, capacity planning, and emergency response.
• Continuous Deployment, more developers were tooling around the deployments of microservices, which have cut down the cost associated with
complexity. Organizations could keep on the trend of migration to microservice architectures.
• In 2020, trends that are prominent and pervasive:
• High microservices market growth, 22.5% in USA and overall, 27.4%.
• Cloud adoption, organizations and their software delivery staff is moving away from locally hosted applications and shift into the cloud.
• Observability tools, companies recognize how important observability is for distributed, microservices-based architectures.
• Web services frameworks, developers will be able to use a framework for web services as microservices continue to evolve and offer
development out-of-the-box capabilities and implementation of the service design patterns and code automatically.
• Increased demand for frequent updates to the applications, In response to user demands for interactive, rich and dynamic experiences on
various platforms, microservices can support the frequency demand. It also goes well with the need of scalability and agility to the applications
having high availability, scalability, and easy-to-execute on the cloud platforms

7. Advantages, Concerns and Mitigations
Few Advantages Challenges to look out for
• Because the microservices function independently, each
component can be built in whatever language the developer of
that component prefers.
• During initial stages it’s the complexity. The number of services and its deployment
complexity. Until sorted delivery process, go slow.
• Distribution cost, increased total latency across systems performing the business
function. Carefully considering number of microservices.• Individual components can be updated on their own since their
internal operation is inconsequential to the app as a whole. As
long as they report back the correct data, the app will continue
working.
• Reduction of reliability, more moving parts in the system, the reliability suffers.
Concepts like service mesh, observability and utilization of those tools could help.
• Scaling can be done to each individual component, saving time
and computing resources spent replicating entire applications to
account for load on a single component.
• Any service can call any service, there is no restriction at all. Hence a solid version
strategy of service APIs is a recommended mitigation. Or think of Change Strategy.
Versioning an API is like having your age in your name. Yes, I’m talking to
you John32 and Emmanuel46. And then comes the fallacy of “nested” resources: If the
resource John32 (/john32) has nested resource child (/john32/child), is
the child resource of version 32 as well? Or is it a child when John was at version 32?
What if the child is changing versions regardless of John32? - Zdenek Nemec
In a survey it was found that point-to-point versioning, which is the strategy employed
by most web API developers today, is 45% more costly with 4 different API versions
than a Compatible Versioning strategy. While Compatible Versioning has a higher initial
cost, over time, it provides huge cost savings. Change Strategy embraces Compatible
Versioning strategy.
• A component no longer meeting the need of its application can be
replaced without affecting the app as a whole.
• Applications can be decentralized between multiple cloud
providers, servers, and other services both local and remote.

8. Services and Libraries
Services
Loosely Coupled
Easily Upgradeable
Libraries
Tightly Coupled
Complicated Jars
Componentization via services : Teams must prefer distributing
components as services rather than libraries

9. Microservices important aspects - Service
discovery
• When using client-side discovery, the client is responsible for determining the network locations of available service instances and load balancing requests across them.
• Netflix Eureka is a service registry. It provides a REST API for managing service-instance registration and for querying available instances. Netflix Ribbon is an IPC client that works
with Eureka to load balance requests across the available service instances.
• relatively straightforward and, except for the service registry, there are no other moving parts.
• since the client knows about the available services instances, it can make intelligent, application-specific load-balancing decisions such as using hashing consistently.
• A significant drawback of this pattern is that it couples the client with the service registry. One must implement client-side service discovery logic for each programming
language and framework used by your service clients.
• When using server-side discovery The client makes a request to a service via a load balancer. The load balancer queries the service registry and routes each request to an
available service instance.
• The AWS Elastic Load Balancer (ELB) is an example of a server-side discovery router.
• Some deployment environments such as Kubernetes and Marathon run a proxy on each host in the cluster. The proxy plays the role of a server-side discovery load
balancer.
• The service registry is a key part of service discovery. It is a database containing the network locations of service instances. Few examples are, Etcd, consul, and
Apache Zookeeper
…

10. Microservices important aspects - Service
registration
• When using the self-registration pattern, a service instance is responsible for registering and deregistering itself with the service registry. Netflix OSS Eureka client is an example
of this pattern.
• One benefit is that it is relatively simple and doesn’t require any other system components.
• However, a major drawback is that it couples the service instances to the service registry. You must implement the registration code in each programming language and
framework used by your services.
• When using the third-party registration pattern, a system component known as the service registrar handles the registration. The service registrar tracks changes to the set of
running instances by either polling the deployment environment or subscribing to events. the open source Registrator project and Netflix OSS Prana are examples of service
registrars.
• A major benefit is that services are decoupled from the service registry. You don’t need to implement service-registration logic for each programming language and
framework used by your developers.
• One drawback of this pattern is that unless it’s built into the deployment environment, it is yet another highly available system component that you need to set up and
manage.

11. Microservices important aspects -
Deployment
• A microservices application consists of tens or even hundreds of services. Services are written in a variety of languages and frameworks. Each one is a mini-application with its
own specific deployment, resource, scaling, and monitoring requirements.
• Multiple service instance per host - We provision one or more physical or virtual hosts and run multiple service instances on each one. Each service instance runs at a well-known
port on one or more hosts. These hosts require pet like treatments.
• Each service instance to be a process or a process group and/or multiple service instances in the same process or process group.
• Relatively efficient resource usage, deploying a service instance is relatively fast, starting a service is usually very fast.
• There is little or no isolation of the service instances, unless each service instance is a separate process. While we can accurately monitor each service instance’s resource
utilization, we cannot limit the resources each instance uses. A stronger dependency of operations on development as there will be technology specific deployments
instructions to be passed on from development to operations, leading to increased risk of deployment errors.
• Service instance per host- we run each service instance in isolation on its own host. Two flavors of this pattern, service instance per Virtual Machine and service instance per
Container. We package each service as a virtual machine (VM) image such as an Amazon EC2 AMI.
• Animator, packer.io are technologies that help build VM images. Boxfuse builds secure and lightweight VM images that are fast to build, boot quickly, and are more secure since
they expose a limited attack surface. CloudNative has the Bakery, a SaaS offering for creating EC2 AMIs. We can configure our CI server to invoke the Bakery after the tests for your
microservice pass.
• Each service instance runs in complete isolation, can leverage mature cloud infrastructure with load balancing and autoscaling coming along by default, encapsulates our
service’s implementation technology.
• Less efficient resource utilization. Each service instance has the overhead of an entire VM, including the operating system, deploying a new version of a service is usually
slow. VM images are typically slow to build due to their size.
…

12. Microservices important aspects -
Deployment
• Service instance per container - each service instance runs in its own container. The processes that are running I a container have their own port namespace and root filesystem.
We can limit a container’s memory and CPU resources. Examples of container technologies include Docker and Solaris Zones.
• Our services need to be packaged as container images, it’s a filesystem image consisting of the application and dependent libraries.
• Containers isolate our service instances from each other. We can easily monitor the resources consumed by each container. Also, like VMs, containers encapsulate the
technology used to implement our services. The container management API also serves as the API for managing your services. Containers are lightweight than VMs.
• Container is not as mature as the infrastructure for VMs, containers are not as secure as VMs since the containers share the kernel of the host OS with one another, we are
responsible for the undifferentiated heavy lifting of administering the container images unless we use GCE and ECS.
• The advancements are aiming to blur the distinction between containers and VMs. Boxfuse VMs are fast to build and start. The Clear Containers project aims to create lightweight
VMs.
• Serverless - AWS Lambda, an example of serverless, natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby code, and provides a Runtime API which allows you to
use any additional programming languages to author your functions.
• The request-based pricing means that we only pay for the work that your services actually perform. Also, because we are not responsible for the IT infrastructure we can
focus on developing your application.
• Few significant limitations, not intended to be used to deploy long-running services, requests must complete within 300 seconds, s, must be written in one of the
supported languages, services must be stateless, services must also start quickly.

13. Microservices important aspects - Data
Handling
• Data access becomes much more complex when we move to a microservices architecture. The data owned by each microservice is private to that microservice and can only be
accessed via its API.
• Different microservices often use different kinds of databases, SQL, NoSQL, Graph.
• A partitioned, polyglot-persistent architecture for data storage has many benefits, including loosely coupled services and better performance and scalability. However, it does
introduce some distributed data management challenges.
• Two-Phase Commit is usually not a viable option in modern applications. The CAP theorem requires us to choose between availability and ACID-style consistency, and availability
is usually the better choice. Moreover, many modern technologies, such as most NoSQL databases, do not support 2PC.
• Another challenge is how to implement queries that retrieve data from multiple services. We may retrieve data using an application-side join, but that’s not the most optimal
solution for various situations.
• The solution is to use an event-driven architecture. In this architecture, a microservice publishes an event when something notable happens, such as when it updates a business
entity. Other microservices subscribe to those events. When a microservice receives an event, it can update its own business entities, which might lead to more events being
published.
• It is important to note that transactions across microservices are not ACID transactions. They offer much weaker guarantees such as eventual consistency. This transaction model
has been referred to as the BASE model (trading some consistency for availability for dramatic improvements in scalability).
• It enables the implementation of transactions that span multiple services and provide eventual consistency. Another benefit is that it also enables an application to maintain
materialized views.
• The programming model is more complex than when using ACID transactions. Often we must implement compensating transactions to recover from application-level failures.
Applications must deal with inconsistent data; the subscribers must detect and ignore duplicate events.
…

14. Microservices important aspects - Data
Handling
• There are a few ways to achieve atomicity with event driven architecture as well-
• The database as a message queue - publish events using a multi-step process involving only local transactions. This approach eliminates the need for 2PC by having the application use local
transactions to update state and publish events.
• Transaction log mining - The events to be published by a thread or process that mines the database’s transaction or commit log. The Transaction Log Miner thread or process reads the
transaction log and publishes events to the Message Broker.
• Event sourcing, rather than storing the current state of an entity, the application stores a sequence of state-changing events. The application reconstructs an entity’s current state by
replaying the events. Whenever the state of a business entity changes, a new event is appended to the list of events. Since saving an event is a single operation, it is inherently atomic.
• It solves one of the key problems in implementing an event-driven architecture and makes it possible to reliably publish events whenever state changes. As a result, it solves data
consistency issues in a microservices architecture.
• because it persists events rather than domain objects, it mostly avoids the object-relational impedance mismatch problem.
• also provides a 100% reliable audit log of the changes made to a business entity and makes it possible to implement temporal queries that determine the state of an entity at any
point in time.
• our business logic consists of loosely coupled business entities that exchange events. This makes it a lot easier to migrate from a monolithic application to a microservices
architecture.
• We can use events to maintain materialized views that pre-join data owned by multiple microservices. The service that maintains the view subscribes to the relevant events and updates
the view. This approach solves the challenge of how to implement queries that retrieve data from multiple services.

15. Migration strategies of monolith to
microservices
• We should stop the temptation to rewrite a monolith to microservices in a BIG BANG way. Martin Fowler reportedly commented that “the only thing a Big Bang rewrite guarantees is a Big Bang!”.
• One application modernization strategy is the Strangler Application. One gradually builds a new application consisting of microservices and run it in conjunction with the monolithic application.
Over time, the amount of functionality implemented by the monolithic application shrinks until either it disappears entirely, or it becomes just another microservice.
• Here are a few strategies of doing this:
• We should stop digging when we are in a hole. That means when we are implementing new functionality, we should not add more code to the monolith. Instead, the big idea with this strategy is
to put that new code in a standalone microservice.
• There are two additional components to this strategy, a router – that receives and redirects the legacy requests to monolith and new functionality requests to newly added microservices, and glue
code - which integrates the service with the monolith.
• A microservice can access the monolith’s data through either of the below listed strategy:
• Invoke a remote API provided by the monolith
• Access the monolith’s database directly
• Maintain its own copy of the data, which is synchronized with the monolith’s database
• The biggest benefit of stop digging strategy is It prevents the monolith from becoming even more unmanageable. The service can be developed, deployed, and scaled independently of the
monolith. However, this approach does nothing to address the problems with the monolith.
• To fix a monolith the solution is to break it, break it in layers, like front-end, back-end, DB Access etc. And another solution could be to start extracting services out of the monolith. A good
approach is to start with a few modules that are easy to extract. This will give us experience with microservices in general and the extraction process in particular. After that we should extract those
modules that will give us the greatest benefit.

16. Let’s hear