WHAT'S IN A NAME? – Microservices and Lagom – Why Microservices?



WHAT'S IN A NAME? – Microservices and Lagom – Why Microservices?

0 0


microservices-lagom


On Github coacoas / microservices-lagom

WHAT'S IN A NAME?

Microservices and Lagom

Why Microservices?

Started monolith. Easy to work with. Easy to deploy. Transactions are simple.

Move to n-tier architecture. Allow spreading out front-end and back-end. But that database...

Big boxes. Every part of every app ended up using the one database server. It was too big otherwise.

Applications became increasingly distributed. Release to "cloud". AWS. Requires a different mindset.

What is a Microservice?

  • Reactive Microservice, specifically
  • As defined by Jonas Boner

Isolated

  • Isolation of failure (bulkheading)
  • Resilience/Recovery from Failure
  • Easier than ever with virtualization/containerization

Asynchronous

  • Microservices must be absolutely decoupled
  • Synchronous calls == Tight coupling
  • Asynchronous allows for failure

Autonomous

  • Each service acts on its own
  • Seperate processes, CI/CD
  • Even different teams and different languages

Single Responsibility

  • Describe what it does in one sentence
  • "Manages friend relationships between users"
  • NOT "Manages orders and processes payments" - split that into another service

Exclusive State

  • Owns its own data
  • All access goes through the API
  • Use the appropriate data store for the service (Cassandra/ElasticSearch/PostGreSQL)
  • Stateless, of course, is also encouraged!

Mobility

Must have an always-available address

Where that address points can move. Location Transparency

Come in systems. One microservice is no microservices

Wait a minute...

There wasn't anything about size in there. How many lines of code?

shudder It's not about the size

There are only two hard problems in computer science: cache invalidation and naming things - Phil Karlton There are reasons for this, of course! We work with extremely abstract concepts that don't lend themselves to names very well

Monad

AbstractSingletonProxyFactoryBean

Object-Oriented Programming

How big should a microservice be?

As small as possible & as big as necessary

Lagom

Lagom 1. Swedish: enough, sufficient, just right. 2. A new opinionated microservices framework from Lightbend Between Akka and Lagom, the Swedes are taking over naming. Next product: Lightbend BorkBorkBork!

Disclaimer

Lagom is an early release (M1) product. There will be updates and changes between now and final 1.0.0 release. Do not use in production. Do not taunt Lagom. Documentation for Lagom is still a work in progress.

Demo

activator new lagom-demo lagom-java

So, how did we do?

Isolated?

  • Services are broken out in individual projects.
  • Seperate projects for API and implementation
  • Short-circuiting implemented by default

Asynchronous

  • All service APIs are implemented as ServiceCall<Id, Request, Response>
  • invoke() method responds with CompletionStage<Response>
  • Making it block requires additional effort!

Autonomous

  • Independent sbt builds
  • Allows for integration with external Lagom projects:
    lazy val helloworld = lagomExternalProject("helloworld",
      "sample.helloworld" %% "helloworld-impl" % "1.0")
                                    
  • Does not require Lagom for external services

Single Responsibility

  • OK, this one is really on the developers
Still, the ease of creating new services lends itself to keep the individual projects small

Exclusive State

  • Provides Cassandra integration out of the box.
  • ES/CQRS integration requires interfacing through the API

Mobility

  • Utilizes Akka actors/clustering
  • Current supported deployment environment is ConductR
  • I expect the community will quickly implement other deployments

For more information:

WHAT'S IN A NAME? Microservices and Lagom