The document discusses how agile innovators are transforming enterprise software development through microservices, containers, DevOps, APIs, and cloud technologies to enhance efficiency and speed. It outlines the limitations of traditional monolithic architectures, the rise of microservices as a solution to these challenges, and the benefits these methods offer such as scalability, resilience, and organizational agility. The document also highlights the necessary cultural and operational changes for successful microservices implementation and the complexities involved.

1. REIMAGINE
TECHNOLOGY
Architecting for speed
Jesper Nordström
Tomas Betzholtz
How agile innovators accelerate growth through microservices, containers, DevOps, APIs and cloud

2. Cutthroat competition requires enterprises to
transform how they build and deliver software
 In the digital age, every company is a software company, and software is the key differentiator
 To stay in the game, businesses must rapidly and continuously upgrade their applications with nonstop availability
 Companies that lack the capacity to experiment, innovate and get new features out quickly will lose out
“Software is eating the world”
Marc Andreesen

3. Problems with traditional application architecture
 Many enterprises still sit on large, monolithic apps with huge
unmanageable codebases
 Monoliths don’t support rapid improvement of functionality
‒ Releasing a small change requires whole app to be deployed
‒ Updates requires growing amount of coordination
 Comprehensive releases with longer cycles means higher risk
 A broken update can cause the entire application to crash
 New developers must spend months learning the codebase
3

4. Problems with traditional application architecture
The blame game: Dev vs Ops rather than DevOps
“What do you mean it doesn’t work in
production, it works on my laptop”?
 When things go wrong, the blame game begins…
 … and the business starts talking about outsourcing because
they’re losing trust in IT

5. The rise of microservices
Changing the fundamentals of enterprise application management.
 The microservices architecture has quickly gained traction as a
new way to think about structuring apps
 A conceptual approach, not a defined framework
 The first architectural style of the DevOps era: embraces
DevOps and Continuous Delivery practices
 Solves many of the problems with large monolithic apps
5

6. What are microservices?
 Perform a single business function
‒ Focus on doing one thing well
‒ Have clearly defined interfaces (bounded context)
 Autonomous
‒ Can be changed and deployed independently
‒ Have minimal dependency on one another (loose coupling)
 Communicate via language/platform-agnostic APIs
‒ Can be developed in any language
6

7. What are microservices?
 Small
‒ Minimal but complete
‒ Small enough to be managed by a “2 pizza team"
‒ Should conceptually fit in a developer’s head
 Managed by decentralised, cross functional product teams
‒ Small empowered teams
‒ Manage all aspects of development
‒ Include every role necessary to deliver the service
‒ Each team responsible for a business function composed of
one or more services
7

8. Conway’s law
8
“The interface structure of a software system
will reflect the social structure of the
organisation that produced it.”

9. What are microservices?
Monolithic vs microservices architecture
MICROSERVICES ARCHITECTURE
User Interface
Business Logic
Data Access
Layer
DB
User Interface
Microservice
Microservice Microservice Microservice
DB DB DB
MONOLITHIC
ARCHITECTURE
Microservice
DB

10. Microservices building blocks
DevOps, Microservices & APIs, Containers, Scalable cloud Infrastructure
10

11. Microservices building blocks: Containers
Containers - the launchpad for microservices
 Ensures software will run the same every time, independent of
environment
 Easier to move apps from development to production
 Small footprint compared to VM’s
 Can be launched in seconds (compared to minutes for VMs)
 Enable developers to scale apps faster and cheaper
11
Standardised frame for services that packages software in a
complete filesystem with everything needed to run it

12. Microservices building blocks: APIs
 Fast adoption in recent years has established a standard format
for communication and enabled microservices
 Enable faster innovation, new service development and
offerings
 We can combine data from different sources to build new
interconnected technologies and services
APIs - from technical need to business model driver
12
HTTP
An API exposes the functionality of a service or app, allowing it
to communicate with others.

13. Microservices building blocks: Cloud
 Relieves IT from manually configuring and managing individual
apps and machines
 Enables us to spend more efforts on agility and efficiency
Scalable cloud infrastructure
13
App A
VM
Hypervisor
Server
TRADITIONAL SERVER VIRTUALIZATION
App B
VM
App A
VM
Hypervisor
Server
App B
VM
Microservice
Container
Datacenter OS
Server Server
HYPERSCALED CLOUD INFRASTRUCTURE
Server
Microservice
Container
Microservice
Container
Microservice
Container
A software layer aggregates data centre servers into one
massively scaled virtual computer to run distributed apps

14. Microservices building blocks: DevOps
DevOps: “Taking the SH out of IT”
 Provides our framework for developing, deploying, and
managing the container ecosystem
 Has been key in elevating microservices to where it is today
 Key components: Continuous Integration and Delivery
*Wikipedia14
DevOps emphasizes collaboration, communication and
integration between dev, QA and ops. The goal is to establish a
culture and environment where building, testing and releasing
software happens rapidly, frequently and reliably*
THE DEVOPS LIFECYCLE
CROSS FUNCTIONAL
COLLABORATION

15. The benefits of microservices
Fast deployment
 We can change code in one service and deploy it separately
from other parts of the system
 So we can deploy code faster and get new functionality out to
customers sooner
15

16. MICROSERVICES
 Each piece of functionality in a separate service:
 Scales by replicating services as needed:
 Selective scaling means more efficient use of code, reducing the
infrastructure we need
MONOLITH
 All functionality in a single process:
 Scales by cloning the entire application:
 Inefficient as all parts are not equally load intensive and it
doesn’t represent the real demands on the system
The benefits of microservices
Scalability
16

17. The benefits of microservices
 We can use different technologies inside each microservice
mixing languages, frameworks and data-storage technologies
 We can pick the right tool for each job
 We can quickly take advantage of new technologies
 We can try out new technologies on services that is lower risk
Technology Diversity (Polyglot)
17

18. The benefits of microservices
Organisational Agility
CONVENTIONAL APPLICATION ARCHITECTURE:
 One big team works on one big piece of code
 Engineers step on each other’s feet
 Development speed slows exponentially as codebase grows
MICROSERVICES ARCHITECTURE:
 Small, autonomous, empowered teams
 Fewer bottlenecks and less resistance to change
 No need for lengthy integration
 Faster decision making and updates
 Easy for new developers to get on board and learn the code
18
Developers Monolith Delivery pipeline
Developers Microservices Delivery pipelines
MONOLITH DEVELOPMENT LIFECYCLE
MICROSERVICE DEVELOPMENT LIFECYCLE
Build Test Deploy
Build Test Deploy
Build Test Deploy
Build Test Deploy
Build Test Deploy

19. The benefits of microservices
Resilience
 Loose coupling and bounded context limits the failure domain
 Less risk microservices cause system failure if they stop working
 Failure of one instance of has minimal impact on the application
 If all instances goes down, it only impacts the function of the
particular service, and the rest of the app continues to work
 When failing is less risky we can easier experiment and innovate
19

20. The benefits of microservices
COMPOSABILITY AND PORTABILITY
 Microservices are like Lego blocks we can assemble to build
apps for a variety of use cases
 Functionality can be reused and consumed in different ways for
different purposes
 We can easily replace or remove a microservice
 Containers are portable across different platforms and clouds
20

21. Challenges with microservices
Microservices are no silver bullet
21
Microservices provide many benefits but may also come with “costs.” It is has all the associated complexities of distributed systems…

22. Challenges with microservices
A straight paved highway?
22
 DISTRIBUTION
 EVENTUAL CONSISTENCY
 API MISMATCH
 OPERATIONAL COMPLEXITY
 SUBSTANTIAL DEVOPS SKILLS REQUIRED
 SECURITY

23. The microservices premium
The “cost” organisations pay in reduced productivity to learn and manage microservices
23

24. Adopting microservices
RAPID PROVISIONING
 We need capability to spin up a server quickly (go cloud…)
 System automation and regularly pushing code updates are critical to deal with the complexity
RAPID DEPLOYMENT
 With many services we must be able to deploy them quickly to test and production
 Our goal is a fully automated deployment pipeline
MONITORING
 Things will inevitably break
 We therefore need comprehensive monitoring to uncover problems quickly and ability to quickly rollback
DEVOPS AND CONTINUOUS DELIVERY
 Close collaboration between development and operations is key to fast provisioning and deployment
 We want both dev and ops involved in incident management and root-cause analysis to resolve issues quickly
Prerequisites before starting a microservices implementation
24
DEVOPS

25. Adopting microservices
CULTURE
 We need organisational support. Microservices is a new reality and the organisation needs time to manage the shift
 We need to embrace automation and increase our tolerance for risk and learn to fail gracefully, fast and often
ORGANISATION
 The organisational changes required may be the biggest challenge
 Thie means small, agile, product teams that own all aspects of their services and can integrate work frequently
GOVERNANCE
 We prefer decentralised governance but need to manage our evolution to microservices to avoid sprawl.
 We need a team overseeing how elements fit together, architectural decisions, new services and ensuring standards
SECURITY
 More surfaces and complexity raise security requirements
 How authenticate who can speak to whom? How identify illicit traffic? Who can work on which services?
Prerequisites before starting a microservices implementation
25

26. Moving from monolith to microservices
UNDERSTAND THE SYSTEM’S DOMAIN BEFORE SPLITTING OUT SERVICES
 If we get boundaries wrong, we have to make costly changes in service-to-service collaboration later
IDENTIFY NON-CRITICAL FUNCTIONALITY LOOSELY COUPLED TO THE REST OF THE SYSTEM
 Break off one piece at a time and move to the next once it’s working
MOVE GRADUALLY AND ALLOW THE ORGANISATION TO GROW NEW CAPABILITIES
 Build tooling and processes, learn about keeping the new system healthy, and ensure DevOps collaboration works
before ramping up the number of services
BEGIN WITH SOME COARSE-GRAINED BUT SELF-CONTAINED SERVICES
 Coarse-grained services mean fewer network calls between monolith and microservices
 We can fine-grain the services as implementation progresses
MINIMISE CHANGES TO THE MONOLITH FOR SUPPORTING THE TRANSITION
 To lower maintenance cost and reduces the impact of the migration
With the foundational capabilities in place, our organisation is ready for a first system using a handful of microservices
26
1
2
3
4
5

27. Moving from monolith to microservices
ENABLE FEATURE TOGGLING TO SWITCH BETWEEN THE NEW SERVICE AND THE MONOLITHIC CODE
 We want to prepare for a smooth load transfer to the new service
 Iteratively deprecate similar functionalities
DESIGN AND DEVELOP THE INTEGRATION
 When part of the app is redesigned, we can write glue code to support communication with the new services.
THE NEW MICROSERVICES SHOULD BE SELF-CONTAINED
 With their own runtime environment, deployed on infrastructure physically or logically isolated from the monolith
CREATE STANDARDISED SERVICE TEMPLATES WITH COMMON ELEMENTS
 To lower ramp-up time for development teams and create standardisation for operations
GOING FURTHER THAN A HANDFUL OF SERVICES WILL REQUIRE MORE EFFORT
 Such as tracing business transactions through multiple services and automating your provisioning and deployment
by completely adopting Continuous Delivery
With the foundational capabilities in place, our organisation is ready for a first system using a handful of microservices
27
6
7
8
9
10

28. Tools
The Microservices Ecosystem
28

29. Further Reading
29
Read our full article about microservices
on Slideshare or 3gamma.com

30. UNITED KINGDOM
3gamma UK Ltd
The News Building
3 London Bridge Street,
London SE1 9SG
United Kingdom
Phone +44 (0) 203 743 6104
GROUP HEAD OFFICE
3gamma Group
Drottningtorget 5
SE-411 03 Göteborg
Sweden
Phone: +46 31 309 7910
SWEDEN
3gamma Sweden AB
Centralplan 15
SE-111 20 Stockholm
Sweden
Phone: +46 8 748 0330
DENMARK
3gamma ApS
Frederiksborggade 15
DK-1360 Copenhagen K
Denmark
Phone: +45 53 700 400
UNITED KINGDOM
3gamma UK Ltd
Manchester Business Park
3000 Aviator Way,
Manchester M22 5TG
United Kingdom
Phone +44 1928 796800
REIMAGINE
TECHNOLOGY