1. Building Mirco Services with Go
&
Manage with Mesos
Pravin Mishra
Twitter: pravinmishra88

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

6. Growing systems beyond the limits

7. Therefore, Microservices

8. Microservices are small, autonomous services
that work together

9. Small, and Focused on Doing One Thing
Well

10. Functional system decomposition into
manageable
and independently deployable components

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”

13. Independent Deployability

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

18. Building REST Services in Go

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.

21. Why Go?

Good performance

Easy concurrency

Easy error handling

Safety

Fast development time

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.

26. Mind It Please

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

30. Continuous Build, Integration, and Deployment

31. Can you release new, well-tested version of your
software in one day?

32. 
Integration issues

Bringing software into production is hard

Takes a lot of time

Error prone

33. The system must be able to build and tested
automatically.

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

36. Jenkins
Distributed, open source CI tool, which
allows continuous integration

37. Repeatable build/test of software projects

38. Testing

Automate everything
If it hurts, do it more often. Continuously.
Fail fast.

Integration testing

Unit testing

Functional testing

39. Large community, rich plugin ecosystem

40. Benefits

Code is always in the consistent state

Code always compiles

Automatic tests

Automatic feedback on production readiness

41. Mesos
General-purpose cluster manager

42. Represent many machines as a single entity

43. Mesos is a scalable and distributed resource
manager designed to manage resources for
data centers.

44. Marathon
Mesos framework that provides private PaaS
Manages long-running tasks

45. Easily scale apps to N instances

46. Automatically restarts failed app instances

47. Challenges

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.

50. Thanks