Tips on Writing Go Microservices for Kubernetes

Erik OstermanCloud Architecture & Platforms, Release Engineering & CI/CDLeave a Comment

Kelsey Hightower, a Google Developer Advocate and Google Cloud Platform evangelist, recently gave a very helpful screencast demonstrating some of the tips & tricks he uses when developing Go microservices for Kubernetes & docker. Among other things, he recommends being very verbose during the initialization of your app by outputting environment variables and port bindings. He also raises the important distinction between readiness probes and liveness probes and when to use them. Lastly, in the Q&A he explains why it's advantageous to use resource files instead of editing live configurations because the former fits better in to a pull-request workflow that many companies already use as part of the CI/CD pipeline.

The 12-Factor Pattern Applied to Cloud Architecture

Erik OstermanCloud Architecture & PlatformsLeave a Comment

Heroku has deployed more services in a cloud environment than probably any other company. They operate a massive “Platform-as-a-Service” that enables someone to deploy most kinds of apps just by doing a simple git push. Along the way, they developed a pattern for how to write applications so that they can be easily and consistently deployed in cloud environments. Their platform abides by this pattern, but it can be implemented in many ways. 

The 12-factor pattern can be summed up like this:

Treat all micro-services as disposable services that receive their configuration via environment variables and rely on backing services to provide durability. Any time you need to make a change it should be scripted. Treat all environments (dev, prod, qa, etc) as identical.

Of course, this assumes that the cloud-architecture plays along with this methodology for it to work. For a cloud-architecture to be “12 factor app” compliant, here are some recommended criteria.

1. Codebase

  1. Applications can be pinned to a specific version or branch
  2. All deployments are versioned
  3. Multiple concurrent versions can be deployed at the same time (e.g. prod, dev, qa)

2. Dependencies

  1. Service dependencies are explicitly declared and loosely coupled
  2. Dependencies can be isolated between services
  3. Services can be logically grouped together

3. Config

  1. All configuration is passed via environment variables and not hardcoded.
  2. Services can announce availability and discover other services
  3. Services can be dynamically reconfigured (E.g. using feature flags or changing environment)

4. Backing Services

  1. Services depend on object stores to store assets (if applicable)
  2. Services use environment variables to find backing services
  3. Platform supports backing services like MySQL, Redis or Memcache

5. Build, release, run (PaaS)

  1. Automation of deployments (build, release, run)
  2. All builds produce immutable images
  3. Deployment should result in zero down-time

6. Processes

  1. Micro-services should consist of a single process
  2. Processes are stateless and share-nothing
  3. Ephemeral filesystem can be used for temporary storage

7. Port binding

  1. Services should be able to run on any port defined by the platform
  2. Service discovery should incorporate ports
  3. Some sort of routing layer handles requests and distributes them to port-bound processes

8. Concurrency

  1. Concurrency is easily achieved by replicating the micro-service
  2. Scale automatically without human intervention
  3. Only sends traffic to healthy services

9. Disposability

  1. Services are entirely disposable (not maintain any local state)
  2. They can be easily created or destroyed
  3. They are not upgraded or patched (just redeploy!)

10. Dev/prod parity

  1. All environments function the same way
  2. Guarantees that all services in an environment are identical
  3. Code runs the same way in all places

11. Logs

  1. Logs treated as structured event streams (e.g. JSON) that can be subscribed to by multiple consumers
  2. Logs collected from all nodes in cluster and centrally aggregated for auditing all activity
  3. Alerts can be generated from log events

12. Admin processes

  1. It should never be necessary to login to servers to manually make changes
  2. APIs exist so that everything can be scripted
  3. Regular tasks can be scheduled to run automatically