The document discusses the evolution of software development from traditional monolithic structures to modern microservices architecture enabled by cloud technologies. It outlines the challenges and benefits of microservices, emphasizing the need for proper development practices and the importance of automation. Key takeaways include the necessity of understanding business needs, starting small, and the iterative nature of adopting microservices.

1. Think Big
(enabled by the Cloud)
Build Small

2. What we’ll cover
• The way we used to (or still) build software
• Timing is everything - Hello Cloud
• A better* (not easier) way to build software
• Not a silver bullet
• How to get started

3. Evolution of Software
Development
• Long planning, gather requirements, build one big thing
• Iterative planning, ship fast, continuous delivery, still build
one big thing
• Everything becomes an API, mobile on the rise
• Automate all things - DevOps
• Mostly, still building one big thing - Monolith (or many - still big -
things, SOA)

4. The Monolith
Server
The Monolith

5. The Monolith (closer look)
The Monolith
Module 1
Module n
Module 2 …

6. • Upgrade server OS
• Upgrade framework
• Modify module n
• Ship new code
• Adopt some new technology
The Monolith Struggle

7. (Hard) Lessons Learned
• Codebase becomes huge - Difficult to maintain, on-board
new members
• Tightly coupled code
• Tied in to a specific technology, no room to explore
something new or attract more diverse talent
• Change is “expensive” and risky
• Not shipping fast enough

8. On Cloud 9
• Servers on demand - no more slow, painful provisioning
• Best industry practices available to everyone
• API’s to manage servers and services
• Ease of deployment
• “Infinite” scalability / elasticity

9. Perfect Timing
• Finally, we can afford the operational cost of breaking the
monolith
• Provisioning new services can be fast and cheap
• No need to pre-invest in infra-structure, invest as you go
• New cloud services offering automation on so many levels
• The rise of containerization (no more “but it works on my local”)

10. A New Hope (any Star Wars fans out there?)
• “Microservices is an architectural style that structures an
application as a collection of loosely coupled services,
which implement business capabilities”
• Divide and conquer - your business isn’t just one
department, why should your software be?
• Iterate fast and cheaper, easier to experiment
• Identify and isolate areas of experimentation, R&D

11. Microservices (oversimplified)
Server 1
Service 1
Server 2
Service 2
Server n
Service n
…
APIAPI
API
Service 1 Service 2
APIAPI

12. Micro-service Benefits
• Smaller, loosely coupled components, easier to manage,
refactor
• Each service, only communicating with the outside world via
its API
• Adopt best technology / tools for each use case
• Each service owns its own data (enables polyglot persistency)
• Scale per service as needed, more fine grained control
• Self organizing teams

13. Who’s in?
and many more…

14. With great power…
• Not a silver bullet, it still requires solid development and
architectural practices
• Many moving parts / Complex architecture
• Automate automate automate
• Setting up an integrated development environment

15. How do I get started?
• Truly understand your business and your data
• Identify areas of responsibility and relationships between
them
• Educate yourself on microservices, build some pet projects
(internal tools are ideal candidates)
• Implement a small, low-risk module as a micro-service
• Measure impact (time to ship, etc.)
• Wash, rinse, repeat

16. Key Takeaways
• Micro-services are not easy and are not for everyone or for every
use case
• You shouldn’t consider micro-services if you don’t understand your
data
• If you can’t build a good monolith, simply opting for micro-services is
not going to fix anything
• Getting it right is a constant iterative process
• Start small. Experiment.
• Automation is King

17. Thank you!
@IraklisAlex
Iraklis Alexopoulos