-> -> I attended the OSCON 2018 in Portland OR on July 18 – 19. Here are my take-away.
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 Kubernetes has become the de facto container orchestration platform, and the community focuses on other pain points:
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:
- 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.
- Blue/Green Deployment: jenkins tags each deployment with
BUILD_NUMBERand push the meta data into the kubernetes deployment.
- Traffic Shifting: istio then tune the envoy to load balance the blue/ green deployments.
- Observation: Prometheus and Grafana can monitor the error rate for the blue/green developments.
- Judgement: we can make a decision based on the observation, or automate with tools such as Spinnaker.
The TypeScript is highly influenced by the Benjamin C. Pierce’s work, Types and Programming Languages.
- It introduces new language constructs to handle the polymorphism in the
FooType | BarTypeand
- The handler function is defined as
- The endpoints are plumbed with Phoenix
- 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.
The scalability challenge: 750M searches per day, 15B flight searches annually.
- 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.
The services to migrate fall into the following categories:
- New services
- Lift and shift: low pain, low gain.
- 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.
- Embracing cloud service ecosystem, Amazon build services faster than you can adopt.
- Internalizing cloud economics, see Cloud optimization circus.
- Accommodate security and control from the beginning.
- Build resilient service, and test with intentional failure, see Vegas rule.
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.
- Hyperledger: a open source blockchain framework.
Assume services without circular dependencies, the root service can call upstream services, each in turn can call upstream services, and so; thus the complexity is , aka exponential growth.↩
Assume the upstream services availability is 99.99%, your service’s availability falls to 99.9% with total 10 API calls are made.↩