2. 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
3. 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
4. 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
5. Problems of Software Monoliths
Huge and intimidating code base for
developers
Development tools get overburdened
Scaling is limited
11. 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
12. 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”
14. 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
15. 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
16. 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
17. 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
19. 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
20. 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.
22. Simple and easy
Go only contains 25 keywords
Python 3.5.0: 33
Ruby 2.2.0: 41
ANSI C: 32
23. Standard Library
net (http, mail)
archives (zip, tar, gzip)
encodings (json, csv, xml)
cryptography (aes, des, md5)
html template system
24. 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
25. I love about Go. I hope to see more languages
adopt this in the future.
27. 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
28. 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
29. 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
34. Upon commits, the system is immediatly and
automatically 'Integrated'
35. 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
48. 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
49. 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.