OSCON 2018 Notes

OSCON 2018

I attended the OSCON 2018 in Portland OR on July 18 – 19. Here are my take-away.

Keynote

Tim O’Reilly delivered the keynote, Open source and open standards in the age of cloud AI and asked a profound question: in the age of cloud AI, are the traditional open source allies, — big corporation such as Google, and Amazon, — turning from collaboration to competing against us?

The open source movement emerged from the great minds’ generosity, and endorsed by IBM with other giant corporation. Both parties benefit from the cooperation until the we hit the top of the S-curve. The relationship MAY change from the cooperation to competition. This also happened in the national level, see Why Nation Fails.

Are we there yet? And if so, what shall we do?

The flourishing Kubernetes ecosystem

The Kubernetes has become the de facto container orchestration platform, and the community focuses on other pain points:

Service Mesh

In the microservice era, the monolithic service is decomposed to many smaller, more modular microservices. The complexity of inter-service grows exponentially1 and the availability of your service is on the mercy of all upstream service2. To build a robust distributed system, we have to manage the upstream services with:

  • caching
  • retry
  • timeout
  • rate limiting
  • circuit breaking, etc

We can certainly build them in the client-side libraries, such as Hystrix; but this approach does not scale in the current polyglot environment. Since deploying services becomes so trivial, why not just wrap our service with a proxy with all good bits?

Envoy and Istio take this approach, aka sidecar pattern, and support more advanced features for continuous delivery, such as traffic shaping, and traffic shadowing. See the demo from Red Hat’s Christian Posta for more details.

Canary in the continuous delivery

Darren Bathgate also discussed the canary in the continuous delivery. These are tools used in the four phases of canary:

  1. Blue/Green Deployment: jenkins tags each deployment with BUILD_NUMBER and push the meta data into the kubernetes deployment.
  2. Traffic Shifting: istio then tune the envoy to load balance the blue/ green deployments.
  3. Observation: Prometheus and Grafana can monitor the error rate for the blue/green developments.
  4. Judgement: we can make a decision based on the observation, or automate with tools such as Spinnaker.

Emerging Languages

TypeScript

The TypeScript is highly influenced by the Benjamin C. Pierce’s work, Types and Programming Languages.

  • TypeScript can infer the type from local context for better interoperability with javascript.
  • It introduces new language constructs to handle the polymorphism in the javascript land, such as FooType | BarType and keyof.

Elixir and Phoenix

Jay Hayes build a phoenix knockoff in dazzling 40 minutes, it highly entertaining and sheds some lights of the framework:

  • The handler function is defined as Endpoint.
  • The endpoints are plumbed with Phoenix Router DSL, get, post.
  • The middleware is composed with Phoenix’s Controller. To be honest, I did not quite follow the meta programming under the hood as my mind halted and the stomach called for the lunch.

Case study

Expedia’s journey to the Cloud

The scalability challenge: 750M searches per day, 15B flight searches annually.

Cloud Migration Strategy

  • Invest to drive the rate of change.
  • Know the landscape.
  • Define your cloud native.
  • Form your Guardrail.
  • Getting unstuck: eliminate the ambiguity and apply growth mindset.

Migration Tactics

The services to migrate fall into the following categories:

  • New services
  • Lift and shift: low pain, low gain.
  • Deprecate
  • Replatform: untangle for high rate of change
  • Move and tune: move as quickly as you can, then iterate with new tools.

Understanding the dependency graph is important.

Define your Cloud Native

  1. Embracing cloud service ecosystem, Amazon build services faster than you can adopt.
  2. Internalizing cloud economics, see Cloud optimization circus.
  3. Accommodate security and control from the beginning.
  4. Build resilient service, and test with intentional failure, see Vegas rule.

Resources

These are tools and resources mentioned in the talk worthy a look:

  • codefresh: a continuous delivery platform for Kubernetes, it simplifies the helm management.
  • helm: the package manager for Kubernetes.
  • spiffe: some application security framework beyond my understanding.
  • johnny-five: A javascript framework for IoT programming.
  • Hyperledger: a open source blockchain framework.

  1. Assume nn services without circular dependencies, the root service can call n1n - 1 upstream services, each in turn can call n2n - 2 upstream services, and so; thus the complexity is n!n!, aka exponential growth.

  2. Assume the upstream services availability is 99.99%, your service’s availability falls to 99.9% with total 10 API calls are made.