Get Started. It's Free
or sign up with your email address
Rocket clouds
Microservices by Mind Map: Microservices

1. architecture style for applications

1.1. composed of small services

1.1.1. easy to think of it as a bunch of "components" with RESTful APIs

1.1.1.1. hence, "services"

1.1.2. tries to avoid centralized components

1.1.2.1. like a database

1.1.3. driven by cloud deployment options

1.1.3.1. can't "reboot" entire system easily

1.1.3.2. easier to "reboot" small parts

1.1.4. cluster things that change together often

1.1.4.1. if two services change at the same time often they should probably be together

1.1.4.2. using frequency and timing of change to find similar services that you can combine together if it makes sense

1.1.5. benefits

1.1.5.1. each component can be in different languages ,technologies

1.1.5.2. scale up by replicated components needs, not enitre "monolith" application

1.1.5.3. different teams can manage each component

1.1.6. draw-backs

1.1.6.1. remote API calls are more expensive

1.1.6.2. APIs must be more coarse-grained in nature

1.1.6.2.1. e.g., not just a StringTokenizer

1.1.6.2.2. "In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don't perform well. Instead you need to replace the fine-grained communication with a coarser -grained approach."

1.1.6.3. refactoring across the entire system is more difficult

1.1.6.3.1. than doing all "libraries" that are part of a monolith

1.1.6.4. it can be difficult

1.1.6.4.1. requires skilled team to break services apart properly, manage them, etc.

1.2. teams are orginized around "business function," or clusters of capabilities

1.2.1. each of these then becomes a "services" cluster

1.2.2. playing into Conway's Law

1.2.3. "you build it, you run it"

1.2.3.1. a DevOps mentality

1.2.3.2. focusing on a product, not a project

1.2.3.2.1. a project means you hand it off to someone

1.2.3.2.2. a product means you own its entire life

1.3. protocols and such

1.3.1. focuses on dumb pipes with smart end-points

1.3.2. RESTful

1.3.2.1. HTTP

1.3.2.2. presumably, JSON, etc.

1.3.2.3. aka "APIs"

1.3.3. Lightweight messaging buses

1.3.3.1. just do "reliable asynchronous fabric"

1.4. decentralized

1.4.1. each running in it's own process

1.4.2. little programatic governance other than convetion

1.4.2.1. instead of schemas and XML validation things

1.4.2.2. continuous build tools and tests seem to enforce the conventions

1.4.2.3. also, DevOps notions of waking up developers at 3am make them pay attention to quality of the system

1.4.3. little central database

1.4.4. problems

1.4.4.1. security

1.4.4.1.1. data access locked down per role/user and such

1.4.4.2. consistancy

1.4.4.2.1. hard to do enforced transactions across data stores

1.4.4.2.2. needs "eventual consistancy" and such

1.4.4.3. more point of failure that may not be under your control

1.4.4.3.1. need to continually test for failure

1.4.4.3.2. requires even more, APM style monitoring

1.5. using RESTful APIs to communicate with each other

1.6. lends self to containerization, it seems

1.7. probably needs to be stateless services

1.8. definitions

1.8.1. component

1.8.1.1. "a unit of software that is independently replaceable and upgradeable"

1.8.2. libraries

1.8.2.1. "components that are linked into a program and called using in-memory function calls"

1.8.3. services

1.8.3.1. "out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call"

1.9. follow-up ideas

1.9.1. this is a way to describe doing RESTful API services

1.9.2. this is a way of describing The Amazon two pizza team, Google Platform Rant style

2. 12 Factor Apps

2.1. Codebase

2.1.1. There's a single codebase per applications

2.1.2. Many instances, of application

2.1.2.1. Though, "version" is not used

2.1.2.2. Seems to be SaaS-oriented

2.1.3. Each developer can deploy has a copy running on their "local developer environment"

2.1.4. Code used by multiple apps should be factored out to stand-along libraries, etc.

2.2. Dependency Management

2.2.1. Not depending on things being on your deploy envoirnment

2.2.2. Declaring the dependencies needed to the maximum

2.2.3. Using tools to suck in these dependencies

2.2.4. This mostly seems like a reaction to typeless systems

2.2.4.1. Avoids erroring out because you lack a dependency at runtime

2.2.4.2. types systems could have this too (a missing JAR at runtime), but its somewhat less an issue

2.3. Configuration

2.3.1. All of the stuff that's different between deploys, mostly settings and such

2.3.2. Strictly stored seperatly from code

2.3.3. Use environment variables

2.3.3.1. As opposed to .properties and .yml files

2.3.3.1.1. These can be checked in accidently

2.3.3.2. try not to segment by "qa," "staging," etc.

2.3.3.2.1. just have the one settings

2.3.3.3. probably have stubs and .sh files that do a lot of this for you

2.4. Backing Services

2.4.1. Often third party services

2.4.2. Also "middleware" like databases and memcase

2.4.3. Treat access to remote backing services the same as access to local services

2.4.3.1. Each instance of a service is thought of as "resource"

2.4.3.1.1. Two different MySQL database instances are two different resources

2.4.3.2. Access "resources" over URLs

2.4.3.2.1. So you can change URLs (and credentials) around easily with config

2.4.3.2.2. This performs some the safety from OO "encapsulation"

2.5. Build, release, run

2.5.1. The important part here is that configuration is all that's touched by release

2.5.2. build is compiling, building, etc.

2.5.3. release applies the instance specific configuration to the build

2.5.4. there is no revising of past builds, just making new builds

2.5.4.1. reduces "works on my box" problems

2.5.5. use a release management product that allows for easy rollbacks

2.5.5.1. this is generally easy following the back services thing and extracting all configuration

2.5.5.2. rolling back data will be the hard part

2.6. [Stateless] Processes

2.6.1. Each process should be stateless, only using local memory or disk for "transactions," acting on data

2.6.2. Store state in database backing services

2.6.3. Don't use "sticky sessions," and instead use a backing service of memcache or Redis to store user sessions

2.7. Port Binding

2.7.1. A bit unclear about breadth of this one

2.7.1.1. Would I "port bind" a String Tokenizer? A zip code cleaner?

2.7.1.2. What do I make a "service" vs. a "library"

2.7.2. Focus on binding a service to a URL, with port

2.7.2.1. As opposed to a "library" as Fowler & co. call it in a microservice

2.7.3. This is basically a large part of "do microservices"

2.7.4. This implies that you not focus on deploying "inside" Tomcat or HTTPD, but instead of backing a URL (with port) with whatever you want

2.7.4.1. Encapsulating your "service" behind a URL with whatever code you want

2.7.4.2. As opposed to writing to a spec, like WARs

2.7.4.3. Make "services," not "components"

2.7.5. Once again, the configuration lets you swap this stuff in and out

2.8. Concurrency

2.8.1. with stateless, single process per [thingy], scale out works better

2.8.2. but, the DB then just need to scale?

2.8.3. This is kind of unclear, and seems to be a consequence of other things

2.9. Disposablity

2.9.1. Write processes so that they can be killed

2.9.2. Queues will return work to queue to be finished by others

2.9.3. "Crash only design"

2.10. Dev/prod parity

2.10.1. avoid using different backing services and implementations in development and production

2.10.2. introduces too much chance to break things

2.10.2.1. "works on my box"

2.10.3. it used to be hard to use "heavy weight" production tools in development, now it's less hard

2.10.3.1. things like Chef, Puppet, and Vagrant [and Docker] can help use the same tools in both

2.11. Logs

2.11.1. Each component is a process, right?

2.11.2. So, the process just writes its logs out to STDOUT

2.11.3. Not concerned with doing its own log files, log system, etc.

2.11.4. Use some log management things and feed that into stuff like Splunk

2.11.5. Remove "efficiency" of common logging as seen in Java, but so be it.

2.12. Admin processes

2.12.1. Sort of a style of doing admin tasks

2.12.2. Check out your copy of the code, configure it like production (so it uses all the backing services used in production), then update the DB...?

2.12.3. "Having console access to a production system is a critical administrative and debugging tool, and every major language/framework provides it. No excuses for sloppiness here."

2.13. Other stuff

2.13.1. A Java guy asking how this applies to Java, answers not too detailed

2.13.2. Hacker News thread