microxchg 2015 - a two-day conference about
microservices. Each day was made of two parallel tracks. I've put down some notes about the talks I attended.
Day 1
- "Microservices - The One with the Polyglot Portfolio" by James Lewis.
James' talk was very entertaining. He shared a story about a customer project. It was an insurance company whose IT changed from mainframes and a VB.Net 2-/3-tier architecture with strong separation between IT department and business and long delivery cycles to a modern IT architecture. That architecture utilizes:
- Separate products/services are built and maintained by cross-functional product teams plus cross-cutting services. The structure follows Conway's law.
- Agile development (e.g. TDD) using modern technologies (e.g. Go, C#, F#, Node.js, MongoDB, D3, git). With service separation they are now able to select the right tool for a job instead of having to stick to a predefined standard toolset.
- Event sourcing is heavily used. I didn't know event sourcing before - here and here is some introductory information. Essentially, it's about storing a complete change history for entities.
- Extensive monitoring incl. business metrics: As many metrics as possible are gathered to gain detailed insight.
In conclusion, the customer gained reduced costs, increased developer motivation and continuous delivery, and delivered features are faster to business.
- "Gut das ist? Die umgekehrte Architekturbewertung eines Internet-Giganten" by Stefan Zörner.
This talk was in German and about a methodology called inverted architecture assessment: Assess the IT architecture and deduct the implications on business context, IT operations, development or team structure. Stefan showed the Netflix architecture as an example and mentioned some deductions:
- Freedom & responsibility: Small teams act and decide on their own, but take full responsibility. This led to lots of new technologies, increased failure resilience and cross-functional teams, but it's hard to coordinate cross-cutting topics.
- Netflix Open Source Platform is a PaaS on top of AWS (which acts as IaaS).
- Approx. 100 deployments per day, no QA engineers, no release managers.
- The API acts as a remote facade separated per client (web, Android, iOS etc.). With this, teams can develop independently, but redundant API endpoints for each client exist.
Some further links he mentioned:
- Technology radar.
- Netflix tech blog.
- Netflix Open Source Software Center (including a getting started example).
- Sofware Engineering Radio episode on modern cloud-based platforms.
- "Gibt es etwas zwischen Microservices und monolithischen Architekturen?" by Oliver Wegner.
Also in German, this talk presented the journey of otto.de from a monolithic architecture of an e-commerce platform to one based on microservices.
Back in 2011 - long before the term microservice was established - otto.de was built of highly dependent modules, used waterfall processes, and they deployed a major release only once per month. Oliver explained it with the words "from fear arise slow processes" - fear to deploy any changes.
Then they first defined what the new web shop should look like and how it should be operated - a clear definition of the vision was developed and broadly communicated across all departments.
They finally ended up with separated services and teams aligned to a typical order process in e-commerce, plus a bunch of cross-functional services and teams. They do lots of monitoring, continuous stress tests, penetration tests, established "security champs" (one developer per team that is keen on security), do continuous deployment, and have lots of independent teams.
His architectural advice:
- RESTful.
- Shared nothing.
- Vertical design.
- Data governance.
- "Buy functionality when not core functionality".
- Common technologies.
KPIs for IT success:
- Lead time for changes.
- Number of deployments.
- Mean time to recover.
Their blog might be worth a look.
- "The Future of Microservice Security" by Martin W. Kirst & Eric Karge (in German).
This talk was about access control and authentication/authorization between microservices incl. the following scenarios:
- Zone-based access control, e.g. intranet, VPN.
- Password/OTP.
- Peer-to-peer, e.g. via API keys or client certificates.
- Central access control, e.g. OAuth.
Finally, they introduced several token technologies:
- JSON Web Token (supports asymmetric keys).
- Macaroons.
- Simple Web Token.
- "Hybris-as-a-Service: A Microservices Architecture in Action" by Andrea Stubbe.
Andrea presented hybris (an e-commerce service) and its technical successor, the recently launched YaaS (currently in closed beta).
They want to move from a monolith to microservices with the target of being scalable, cloud-based, supporting autonomous/independent teams, providing RESTful APIs and a design for failure. The multi-tenant, cloud-based services are accessible through an SDK and/or API. These services are extensible by other developers following some easy steps (define RESTful API through RAML, integrate other services by reference, create a deployment descriptor, and finally publish on a marketplace). Businesses can build their e-commerce platform picking from those services following a layered approach:
- Backing services (e.g. MongoDB) are wrapped by a core service layer.
- Core services (e.g. auth, document store) do not share backing services.
- Business services (e.g. shopping cart, pricing) sit on top of core services.
- "Microservice Challenges" by Fred George.
Fred's entertaining talk mentioned the following challenges concerning microservices:
- Synchronous vs asynchronous: programming model complexity vs failure resilience.
- Deconstructing the database: a separate data storage layer per microservice vs synchronization challenges.
- Microservices or Clojure: "Clojure loves shared data", leading to tight coupling with the data passed around.
- Choosing architectures and frameworks: mircoservices are still quite fresh.
- No design patterns book yet: information exchange still happens nearly exclusively on conferences and meetups.
- What is a microservice? A taxonomy system is still to be defined.
Day 2
- "Der Agile Monolith – Wie wir unseren Monolithen erfolgreich gehalten haben und warum wir trotzdem auf Microservices setzen." by Oliver Schönherr (in German).
As a contrast to all other talks, Oliver showed how to develop and maintain a monolith in an agile way. The monolithic core application looks like this:
- 1 million lines of Java code (with ten thousands of dependencies).
- Up to 100 developers working concurrently.
- Big bang deployments.
The target was to reduce the time between deployments down to daily deployments. They focused mainly on improving the build process, the tests and the deployment process.
Build:
- Decreased build time from 1 day down to 10 minutes (by moving from a self-developed build system based on Ant to one based on Maven).
- Long-living feature branches led to lots of merge conflicts. So, moving to development on trunk worked out well (TeamCity and a decreasing number of developers helped here).
- Removed the role of a build master. Developers now take care of builds.
Test:
- Moved responsibility for tests from a dedicated QA department into development teams.
- Embrace effort for test maintenance.
- Execution time for the set of critical integration tests is now less than one hour (by a reduced test set, and tests run in parallel).
Deploy:
- Re-implemented their deployment tool (see YADT) for fully automated zero-downtime deployments (with respect to service dependencies).
- Unresolved problem yet: Make the frontend (which stores session information) stateless. This is the main reason why they are not able to deploy more often than once a day.
- Database changes are upward and downward compatible.
- Use a blue-green deployment schema.
- "State of the Art in Microservices" by Adrian Cockcroft.
- The main target is to speed up development.
- Cloud is embraced now.
- Docker appeared, Go is uprising and fits perfectly the Docker story due to less dependencies.
- Release early, release often.
- Product development process: observe (e.g. measure customers), orient (e.g. model hypotheses), decide (e.g. share plans), act (e.g. deploy automatically).
- Break down silos and monoliths. This leads to bug isolation and a limited blast radius.
- Embrace DevOps, e.g. "run what you wrote" by putting developers on call. This leads to more solid code. Treat infrastructure as code. Increase investment into automation, monitoring and tooling.
- Continuous delivery with containerized microservices.
- Conway's law can be inverted: Organize your teams in the way you want your IT architecture to look like.
A microservice definition: Loosely coupled SOA with bounded context.
Adrian also mentioned AWS Lambda (event driven callbacks as cloud service) as an interesting new approach. He presented the schema of Netflix OSS, Twitter microservices and others and how they implemented building blocks for tooling, configuration, discovery, data stores etc.
Recommended books: Lean Enterprise, Release It!, Drift into Failure.
- "Principles of Microservices" by Sam Newman.
This was the best structured and most entertaining talk. Sam wrote a book about building microservices.
First of all: There's no hyphen in "microservices"!!! ;-)
A definition of microservices: Small autonomous services that work together.
There are lots of choices when dealing with microservices. Principles (like the twelve factors by Heroku) may help and provide guidance.
Principles of microservices:
- Modeled around business domain.
- Culture of automation.
- Hide implementation details.
- Decentralize all the things (e.g. introduce self-service; owners, i.e. developers become operators of the software they wrote).
- Deploy independently (e.g. do not run several services on a shared host/VM/container).
- Isolate failure.
- Highly observable.
- "Tipps und Tricks für das Testen von Microservices" by Jörg Pfründer (in German).
- Postel's law (robustness principle) for tests: Test only relevant parts of your data structure in contrast to all detailed bits. This makes tests less flaky and more resilient to irrelevant changes.
- Express yourself: Encapsulate response objects, add human-readable access methods that can also act as blueprint for client implementations.
- Production code is test code: Consumer driven test/contract test. Reuse production client implementation for test client implementation.
- Delude and betray: Mock/stub downstream dependencies of a microservice e.g. by using mountebank or WireMock.
- Better safe than sorry: Run test client for the service to be tested first, then run all other services' test clients. If all tests succeeded, populate the test client for the service to be tested to be used by other services' test runs from now on.
- In general: Deploy quickly and continuously to production. No breaking API changes. Keep changesets small.
- "Microservices - Smaller is Better?" by Eberhard Wolff.
Why microservices?
- Strong modularization.
- Easy to be replaced.
- Small units.
- Continuous delivery.
- Deployment less risky.
- Free choice of technology.
This results in a sustainable development speed.
In theory: Small microservices lead to lots of communication. In practice that's irrelevant.
Conways's law: Desired architecture reflects the project structure.
- A microservice belongs to one team which is responsible for meaningful features.
- Each team builds and deploys features independently.
- Perfect match for agile processes.
- Team size influences microservice size (in terms of features of that service).
The number of services will increase over time. Refactoring across service boundaries is hard, tearing services apart is easier than joining services.
Eberhard's recommendation: Start with bigger microservices rather than with too small ones.
- "Resilience/Service-Discovery and Zerodowntime-deployment in micro-service architectures" by Dr. York Xyander & Dr. Bodo Junglas.
Microservices promise independence. There are several challenges when dealing with microservices:
- Development, deployment & operation.
- Configuration.
- Debugging.
- ...
Service discovery to populate changes in service infrastructure:
- Use your existing config management/provisioning tool like Chef or Puppet.
- DNS (mature, but not comfortable).
- Service discovery service like ZooKeeper, Consul or etcd.
Failover should be handled in business services by failing early or using a circuit breaker. Do not wait for network timeout or rely on failover handling in service discovery service.
York and Bodo presented a failover demo that was based on microzon.
All in all, this conference showed that microservices are an evolving field and still heavily in motion.
The
location was splendid with a superb catering :-)
