A journey from monolith to micro services
-
Upload
pravin-mishra -
Category
Documents
-
view
177 -
download
2
Transcript of A journey from monolith to micro services
![Page 1: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/1.jpg)
Building Mirco Services with Go
&
Manage with Mesos
Pravin Mishra Twitter: pravinmishra88
![Page 2: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/2.jpg)
Today Objectives
• The Pain
• Therefore, Microservices
• Building REST Services in Go
• Mind It Please
• Continuous Build, Integration, and Deployment
• Challenges
• Conclusion
Questions are always welcome
![Page 3: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/3.jpg)
Observed problems
Area of consideration It was all my fault, really? Built collaboratively by several development
teams With traffic load that requires horizontal scaling
(i.e. load balancing across multiple copies of the system)
Observation Such systems are often built as monoliths or
layered systems
![Page 4: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/4.jpg)
Software Monolith
A Software Monolith One build and deployment unit One code base One technology stack (Linux, JVM, Tomcat,
Libraries)
Benefits Simple mental model for developers
One unit of access for coding, building, and deploying
Simple scaling model for operations
Just run multiple copies behind a load balancer
![Page 5: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/5.jpg)
Problems of Software Monoliths
Huge and intimidating code base for developers
Development tools get overburdened
Scaling is limited
Deployment frequency is limited
![Page 6: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/6.jpg)
Growing systems beyond the limits
![Page 7: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/7.jpg)
Therefore, Microservices
![Page 8: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/8.jpg)
Microservices are small, autonomous services that work together
![Page 9: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/9.jpg)
Small, and Focused on Doing One Thing Well
![Page 10: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/10.jpg)
Functional system decomposition into manageable
and independently deployable components
![Page 11: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/11.jpg)
Underlying principle
The term “micro” refers to the sizing: a microservice must be manageable by a single development team (5-9 developers)
Functional system decomposition means vertical slicing
(in contrast to horizontal slicing through layers)
Independent deployability implies no shared state, do inter-process communication
![Page 12: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/12.jpg)
More specifically
Each microservice is functionally complete with...
Each microservice handles one resource (or verb)
Microservices are fun-sized services, as in “still fun to develop and deploy”
![Page 13: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/13.jpg)
Independent Deployability
![Page 14: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/14.jpg)
Independent code base
Each service has its own software repository
Codebase is maintainable for developers – it fits into their brain
Tools work fast – building, testing, refactoring code takes seconds
Service startup only takes seconds
No accidental cross-dependencies between code bases
![Page 15: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/15.jpg)
Independent technology stacks
Each service is implemented on its own technology stacks
The technology stack can be selected to fit the task best
Teams can also experiment with new technologies within a single microservice
No system-wide standardized technology stack also means
No struggle to get your technology introduced to the canon
No piggy-pack dependencies to unnecessary technologies or libraries
It‘s only your own dependency hell you need to struggle with
Selected technology stacks are often very lightweight
A microservice is often just a single process that is started via command line, and not code and configuration that is deployed to a container.
![Page 16: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/16.jpg)
Independent Scaling
Each microservice can be scaled independently
Identified bottlenecks can be addressed directly
Data sharding can be applied to microservices as needed
Parts of the system that do not represent bottlenecks can remain simple and un-scaled
![Page 17: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/17.jpg)
Independent evolution of Features
Microservices can be extended without affecting other services
For example, you can deploy a new version of (a part of) the UI without re-deploying the whole system
You can also go so far as to replace the service by a complete rewrite
But you have to ensure that the service interface remains stable
![Page 18: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/18.jpg)
Building REST Services in Go
![Page 19: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/19.jpg)
Options
Ruby
Don’t repeat yourself’, thus saving time and effort
Python
Less lines of code == means lesser bugs
Nodejs
Easier server-side development at the cost of performance, scalability
Easy async code patterns and great concurrency handling
Go?
![Page 20: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/20.jpg)
So what is Go?
Go is an attempt to combine the ease of programming of an interpreted, dynamically
typed language, with the efficiency and safety of a statically typed, compiled language.
![Page 21: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/21.jpg)
Why Go?
Good performance
Easy concurrency
Easy error handling
Safety
Fast development time
Good libraries to ease my development
![Page 22: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/22.jpg)
Simple and easy
Go only contains 25 keywords
Python 3.5.0: 33
Ruby 2.2.0: 41
ANSI C: 32
![Page 23: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/23.jpg)
Standard Library
net (http, mail)
archives (zip, tar, gzip)
encodings (json, csv, xml)
cryptography (aes, des, md5)
html template system
generic sql drivers
logging system
and many others...
![Page 24: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/24.jpg)
Go tools
gofmt is not the only tool which Go has to offer, many more are available. To name some:
golint to check for style violations
go vet to check for programming errors
go test to test the code
go tool cover to get coverage reports (given tests)
go doc to generate documentation
![Page 25: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/25.jpg)
I love about Go. I hope to see more languages adopt this in the future.
![Page 26: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/26.jpg)
Mind It Please
![Page 27: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/27.jpg)
Fallacies of Distributed Computing
Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning
experiences. The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn‘t change There is one administrator Transport cost is zero The network is homogeneous
![Page 28: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/28.jpg)
Microservices Prerequisites
Before applying microservices, you should have in place
Rapid provisioning
Dev teams should be able to automatically provision new infrastructure
Basic monitoring
Essential to detect problems in the complex system landscape
Rapid application deployment
Service deployments must be controlled and traceable
Rollbacks of deployments must be easy
![Page 29: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/29.jpg)
Evolving interfaces correctly
Microservice architectures enable independent evolution of services – but how is this done without breaking existing clients?
There are two answers Version service APIs on incompatible API
changes Using JSON and REST limits versioning needs
of service APIs
Versioning is key Service interfaces are like programmer APIs –
you need to know which version you program against
As service provider, you need to keep old versions of your interface operational while delivering new
Versions But first, let’s recap compatibility
![Page 30: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/30.jpg)
Continuous Build, Integration, and Deployment
![Page 31: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/31.jpg)
Can you release new, well-tested version of your software in one day?
![Page 32: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/32.jpg)
Integration issues
Bringing software into production is hard
Takes a lot of time
Error prone
![Page 33: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/33.jpg)
The system must be able to build and tested automatically.
![Page 34: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/34.jpg)
Upon commits, the system is immediatly and automatically 'Integrated'
![Page 35: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/35.jpg)
Continuous Integration
“Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.” - Martin Fowler
![Page 36: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/36.jpg)
Jenkins
Distributed, open source CI tool, which allows continuous integration
![Page 37: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/37.jpg)
Repeatable build/test of software projects
![Page 38: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/38.jpg)
Testing
Automate everything If it hurts, do it more often. Continuously.
Fail fast.
Integration testing
Unit testing
Functional testing
Application testing
![Page 39: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/39.jpg)
Large community, rich plugin ecosystem
![Page 40: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/40.jpg)
Benefits
Code is always in the consistent state
Code always compiles
Automatic tests
Automatic feedback on production readiness
![Page 41: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/41.jpg)
Mesos
General-purpose cluster manager
![Page 42: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/42.jpg)
Represent many machines as a single entity
![Page 43: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/43.jpg)
Mesos is a scalable and distributed resource manager designed to manage resources for
data centers.
![Page 44: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/44.jpg)
Marathon
Mesos framework that provides private PaaS
Manages long-running tasks
![Page 45: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/45.jpg)
Easily scale apps to N instances
![Page 46: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/46.jpg)
Automatically restarts failed app instances
![Page 47: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/47.jpg)
Challenges
![Page 48: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/48.jpg)
Further Challenges
Testing the whole system
A single microservice isn‘t the whole system.
A clear picture of upstream and downstream services is needed for integration testing
Transactions
Instead of distributed transactions, compensations are used (as in SOA)
Authentication
Is often offloaded to reverse proxies making use of authentication (micro)services
Request logging
Pass along request tokens
Add them to the log
Perform log aggregation
![Page 49: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/49.jpg)
Summary
Just adopt?
No. Microservices are a possible design alternative for new web systems and an evolution path for existing web systems.
There are considerable amounts of warnings about challenges, complexities and prerequisites of microservices architectures from the community.
Just the new fad? Yes and no. Microservices is a new term, and
an evolution of long-known architectural principles applied in
a specific way to a specific type of systems. The term is dev and ops-heavy, not so much
managerial. The tech landscape is open source and vendor-
free at the moment.
![Page 50: A journey from monolith to micro services](https://reader034.fdocuments.in/reader034/viewer/2022051710/5a6ed1ce7f8b9a7f7e8b4f5f/html5/thumbnails/50.jpg)
Thanks