Why Micro services, what do they solve and a little bit how via GRPC instead of REST, Docker to containerize and Continuous Deployment

1. Micro Services
The What ,Why and a little How ?

2. Before we answer the questions that start with
What and How,
Let us ask the harder questions starting with Why
Why triggers Why not, and the answers will make What and How more
meaningful...

3. But before I start with the Talk, there is just one thing I want to say -
this talk is not only about yakking why Micro Services are the greatest thing that
has ever happened, and why everyone should discard everything in and jump
in;No this talk is more about Systems Engineering than System Architecture; and
a possible solution to the problems of Enterprise SW product development.
Yes, Systems Engineering -a term that needs more focus, has to do with people,
team organization,product/release management, system design and basically
when we talk about MicroServices we are talking about a way of Systems
Engineering!

4. Some Questions that we will try to answer ?
A .Why not Tired Architecture/Application Servers /DB Tier, Web Tier ?
B .Why is this widely adopted or gaining popularity in all high profit companies;
Amazon, NetFlix, Google ? /will we be more profitable if we adopt ?
C. Will This too Pass /do I really need to listen zzZZ ? will you talk about the
wonders of Serverless next ?
(COM, CORBA,EJB, ESB, SOA --SOAP.. REST? what REST ???
E. What has to change for this ?

5. Slide 5 -There is just one more story I want to share, before I
start.. Andy Tanenbaum was a professor and OS researcher, held in high esteem and his books are
very popular; here is an old but interesting debate with Linus Torvalds (note Linux Kernel is Monolithic)
>1. MICROKERNEL VS MONOLITHIC SYSTEM
From: ast@cs.vu.nl (Andy Tanenbaum)
Subject: Re: LINUX is obsolete
Date: 30 Jan 92 13:44:34 GMT
I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error.
Be thankful you are not my student. You would notget a high grade for such a design :-)
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: LINUX is obsolete
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki
Well, with a subject like this, I'm afraid I'll have to reply True, linux is monolithic, and I agree that microkernels are nicer. With a
less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical)
standpoint linux looses.If the GNU kernel had been ready last spring, I'd not have bothered toeven start my project: the fact is that it
wasn't and still isn't. Linux wins heavily on points of being available now. -
http://www.oreilly.com/openbook/opensources/book/appa.html

6. let us start the talk (finally) with a thought
The Problems you don’t know you have, are usually
your biggest Problems.
Most of us fall into two categories
1. Everyone thinks their System is tiered, service oriented, message based , superbly designed...
CLOUD based..
2. Or they think; damn my system is not containerized, not cloud based, not written in Go or Erlang or
whatever, hmm
No architect, or developer is thinking if there is a problem
somewhere, a bigger problem

7. What could be the Problem ?
Maybe your System Architecture is beautiful, theoretically
right, academically correct, full marks slide(5) ?
But if you take a year to release a small feature to
your end customer ?
If we are so slow in feature delivery ?
If we turn estimates into deadlines, and have to then race to deliver on time, but
create horrendous messes in product delivery ?

8. Maybe most SW houses follow a System
Engineering model that is better in producing packed
Noodles than Software ?
We yearn for order and repeatability; but features are usually complex
This is an exaggerated comparison, but most business borrow heavily from
industrial practises. ( Lean from Toyota, Kanban ?)

9. Or maybe our System Architecture has evolved as
per our organization structure ?
Organizations which design systems are constrained to produce
designs which are copies of the communication structures of these
organizations -- Conways law “How Do Committees Invent"
http://www.melconway.com/research/committees.html
This is a problem as basically every team has to throw the ball and
part of the responsibility to another team till it release.
Humans love each other; Teams don’t lose much love between them ?

10. Amazon realized they had a problem around 2001
“If you go back to 2001,” stated Amazon AWS senior manager for product management Rob Brigham, “the Amazon.com
retail website was a large architectural monolith.”
“Now, don’t get me wrong. It was architected in multiple tiers, and those tiers had many
components in them,” Brigham continued. “But they’re all very tightly coupled together,
where they behaved like one big monolith... that monolith is going to add overhead into your process, and
that software development lifecycle is going to begin to slow down.”
we measured the amount of time it took a code change to make its way through that
deployment lifecycle, across a number of teams. When we added up that data, and looked at
the results, and saw the average time it took, we were frankly embarrassed. It was on the order of weeks.”
For a company like Amazon that prides itself on efficiency — for a company that uses robots inside of our fulfillment
centers to move around physical goods, a company that wants to deploy packages to your doorstep using drones — you
can imagine how crazy it was,” he said, “that we were using humans to pass around these virtual bits in our software
delivery process.. (https://thenewstack.io/led-amazon-microservices-architecture/)

11. Amazon turned to SOA ....Jeff Bezos style
Here is a post from ex Amazon Google employee Steve Yegge's that that got published accidently; herecalls that one
day Jeff Bezos issued a mandate, sometime back around 2002 (give or take a year)
● All teams will henceforth expose their data and functionality through service interfaces.
● Teams must communicate with each other through these interfaces.
● There will be no other form of inter-process communication allowed: no direct linking, no direct reads of another
team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via
service interface calls over the network.
● It doesn’t matter what technology they use.
● All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say,
the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
The mandate closed with:
Anyone who doesn’t do this will be fired. Thank you; have a nice day!
https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis
http://www.businessinsider.com/jeff-bezos-makes-ordinary-control-freaks-look-like-stoned-hippies-says-former-engineer-2011-10?IR=T

12. Service oriented architecture promised modular components each providing a web
interface API to interact with it.
A lot of other companies and products embraced SOA as
well;
it was heavily marketed; SOA, Web Services and the like;
But many missed the crucial parts of why they did what they
did. Again

13. Amazon adopted SOA and was working on*
Continuous Delivery
So that they could use SOA and make feature
releases faster and faster....
Remember slide(5); System architecture is not the
end goal; System Engineering has to be
transformed as well..
*http://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

14. We have come to the What Part
Microservices as term was coined around 2011, but was a progression from SOA.
Martin Flower, the famous Thoughtworks consultant had documented many
aspects of this. There is no one definition. Here is one that highlights the why part
into the what :- MicroService is an enabling technology, for continuous
product deployment,using immutable containerized software
modules, that adhere to typed versioned interface and lightweight inter
module communication mechanism.
Typically container management, centralized log and performance collection and
continuous deployment pipeline are needed for a practical robust solution

15. What the *** ?
Yes it was a mouthful as definitions go, I got the liberty and I thought I would make
a bigger one, why not
Now you know why there is no one definition for anything in Software, that
everyone understand in the same way. Here is a better one
https://martinfowler.com/articles/microservices.html
As we are talking about definitions what do you think is a Scrum Master ?
A Master Craftsman in Scrum ? a Master in Scrum ? or a Master of Scrum
(commanding Scrum Slaves)?
... the trouble with humans, everyone has a completely different take on
anything slightly abstract...

16. How do you create a MicroService ?
A. An application is decomposed to smaller set of functionality, each as a
software module exposed over the network usually over HTTP wrapped in a
container
Q But won’t this mean that there will be lot of interactions between services, if we
use WSDL and XMLs the performance ?
Q. Wait HTTP, it does not compress, oh even if I use JSON and REST it will be a
problem, what about the hundreds of connections ?
Q. You mean to say that I have to put TomCat, JBoss, WebSphere.. Xxx
Application platform in each container, this is going to be really heavy ??

17. Still further questions
Q. What, over the network ? What about NW calls , latency , headless master
syndrome, Distributed Computing fallacies ??
Q. Over the network, really, the coding horror of checking if any damn router acts
up ?
Q. Really continuous delivery, my stack depends on xx version of yy so that it will
only work with my neighbours component that uses yy version of xx ....

18. There would be lot more questions as well
If we know all our Problems up-front will we ever start ? It is good to think and
uncover some? and stop thinking and handle some as it comes
Companies that moved to this sort of system engineering were companies that
solved most of these, and though some of this like CD is a definite commercial
advantage and not discussed much
the good new is that many of the solutions they have Open-Sourced

19. Rapidly Changing Interfaces of components needs a versioned and typed
Interface between modules/micro services
REST is good and delivered us all from the horrors of WSDL. But REST has very
poor interface semantics; good for web servers; not for services;( I love REST and
the Stateless Server Concept of REST & HTTP Inventor Roy Fielding!)
Lightweight efficient communications between modules is solved by GRPC &
Protocol Buffer v3 - Feb 2015 - Today, we are open sourcing gRPC, a brand new framework for handling
remote procedure calls. It’s BSD licensed, based on the recently finalized HTTP/2 standard, and enables easy
creation of highly performant, scalable APIs and microservices in many popular programming
languages and platforms https://developers.googleblog.com/2015/02/introducing-grpc-new-open-source-http2.html

20. There is a lot more to GRPC...
There are 201 slide here
https://www.slideshare.net/borisovalex/enabling-googley-microservices-with-http2-
and-grpc
Suffice to say that Netflix moved its 10 billion microservices to GRPC
Really ? Hmm, seems so - We’ve also undergone a huge evolution of our Runtime Platform. From
replacing our old in-house RPC system with gRPC ..
https://medium.com/netflix-techblog/neflix-platform-engineering-were-just-getting-started-267f65c4d1a7
(July 5 2017)
https://www.forbes.com/sites/janakirammsv/2017/03/01/grpc-the-protocol-of-microservices-joins-the-cloud
-native-computing-foundation/#288c270f4b0a

21. Why Containers ?
First why VMs ? HW virtualization; Plonk a big Server and create as many VM’s as
you wish ? Each VM is a JAILED OS; provisioned CPU, RAM DISK
Why Container? To Start with Containers are a JAILED process;
A process that is isolated and had limited CPU, memory, Resources - Control
Groups (cgroups) based on chroot? Released in 2006 by Google, merged to Linux
Kernal 2.6.24
Each microservice is usually one GRPC process; You can have Tomcat , JBoss
and what ever you like in the Container; But with GRPC it is acutally serverlss

22. If it is so much why did it become pretty popular
I don’t know
But I would say how Docker did Container Management is the key and its perfect
delivery vehicle for Micro Services
It is not really well appreciated; But each layer in a Dockerfile build Docker Image
is immutable
Docker is delivering the promise of immutable infrastructure.
Many of the things of Continuous Deployment works because
of this like rollback, easy upgrade etc...

23. There is a lot more about Docker
Think about it,if you have a zillion services will it be practical to have the overhead
of virtual machines
Do you know that Docker containers can easily emulate your favorite distribution
which can work on any Linux OS ?? (as long as it is x86 based)
That you can map volumes, and devices of the host into it
And Docker Registry

24. Before I stop
Things which are very relevant in this space but which we did not talk about
Service Discovery - Consul
Container Management - Kubernetes, (OpenShift)
Parting words
How To - GRPC, Docker , Consul Kubernetes, No shared nothing
Why to - Decoupled /decentralized fast feature delivery. Polyglot Stack, Freedom
Problems - Monolithic Frontends ? ...