VP App Dev pitch deck
David Soul
Cloud Native Apps, Microservices & Platforms
PCF is the 1st and only cloud native vendor at the moment
Dev and Ops teams have to change together
Our customer base was struggling with partial transitions and continuous delivery
What’s the alternative to an integrated cloud native solution?
Spring Boot is bringing microservices to the Java enterprise
Pivotal Cloud Foundry is how your deploy Spring Boot applications.
Would you rather have developers spend their time building a platform, or using one?
It’s what some enterprises are doing today: adopting cloud a-la-carte today, using a combination of individual cloud services or technologies: Just EC2 + services. Just Docker. Docker with Puppet/Chef/Ansible/SALT. MesosSphere or Kubernetes with Docker on EC2. etc etc.
Non-native, unintegrated approaches don’t offer the economy of scale inherent in a cloud native approach – partial approaches miss the mark. Most enterprises are considering to deploy multiple cloud applications, and would save $$$ if the process was repeatable – which you don’t get from using point solutions.
Partial adoption places your efforts at the mercy of “Day 2” adoption issues – rife throughout the various, unintegrated layers of a cloud native solution. The next app is almost certain to require a different set of choices and trade-offs, so any economy of scale from the last effort goes out the window.
Cloud native apps build on a repeatable, structured approach to the app framework, the elastic runtime and the infrastructure automation. Why reinvent things for every project?
12 factor app development and architecture, cloud resource connectivity
Security
Container Automation (create/scale more containers)
IDM
Log and metrics aggregation
APM
Etc etc
Now let’s spend a more time going a little deeper on the Application Framework.
These are the tools that provide all the functionality architects and developers need to design and deliver cloud native applications.
In particular these tools should enable creating microservices and 12 factor apps with minimal friction.
Organizations using these tools, and the supporting platform capabilities, create scalable secure applications while releasing new features every week, if not daily.
Microservices allow always keeping the trains running because each service is deployed independently in loose coordination with the rest.
Most of the consumer web applications that we take for granted are delivered this way.
Many of them even integrate with each other.
Twitter, Facebook, Google, flickr, Uber, Apple… none of them wait on each other to go ahead and deploy the applications you use everyday, but they use each other.
If microservices describe how the architect your application, what principals do you use for the actual code.
A good place to start is the 12 factor app principals.
Learn from and use the same methods that the original cloud native do.
These 12 simple principles give a surprising amount of detailed, prescriptive advice on how to write your applications to be ready for cloud deployment. They describe a contract between the developer and the cloud platform that, if followed, will allow an application to scale with cloud native resilience.
The other side of that contract must be provided by a platform like Pivotal Cloud Foundry.
Spring Boot is an open source Java framework optimized for developing microservices that is rapidly being adopted and has been embraced cloud native companies like Netflix.
In addition to the rapid development of simple microservices, Pivotal has also embraced a number of Netflix Open Source components to provide additional microservice capabilities like services discovery, dynamic configuration and circuit breakers.
This means that you can use the practices and tools relied on by Netflix and others while leveraging the Java skills you might already have.
Finally, we wrote the book on how these microservices are used in cloud native architecture and how to get there.
We should have copies here, if you'd like one, or you can get the PDF for free online.
Now the original Cloud Foundry runtime was the DEA, Droplet Execution Agent
We rewritten it in Go, hence Diego and a twist Renee French’s awesomely cute gopher icon.
Let’s introduce some core Diego concepts.
(Credit Onsi)
Cloud Foundry has a brain that manages cells
Almost all platform components communicate takes place through a scalable bulletin board system based on etcd*
*Auctions don’t
Let’s show some more architectural detail.
Each cell contains an auction rep and an executor that manages the containers. You can see the containers in each cell.
Brain communicates work through the auctioneer.
The auctioneer asks cell reps to put forward bids to run tasks and processes
The winning cell takes on the workload.
Also, everybody is talking about containers. Pivotal Elastic Runtime is actually one of the most mature linux container scheduling environments in the world.
The dynamic container scheduler in the Runtime distributes applications across a cluster. When there is more work, it gets balanced across the remaining of the capacity.
The platform also monitors the applications, and if any of them crash, they get restarted and rebalanced across available capacity. None of this requires human intervention.
The platform also monitors the applications, and if any of them crash, they get restarted and rebalanced across available capacity. None of this requires human intervention.
The platform also monitors the applications, and if any of them crash, they get restarted and rebalanced across available capacity. None of this requires human intervention.
Introducing tasks, short-lived work units
Garden is a platform-neutral API for containerization
The API talks to specific backends for each infrastructure.
We’re also moving Garden to match the RunC implementation from Open Container Initiative, so we’ll be able to offer RunC compatibility.
(Credit Onsi)
Now we’ve covered a high level introduction to runtime concepts like the brain, cells and bulletin board system,
I wanted to show how we extended this to offer 4 new capabilities not found in the original runtime.
Run Dockerized applications, .NET, Workers and tasks, and a local runtime environment
Some caveats, for example Cloud Foundry is focused on 12 Factor Docker image so no we don’t want to use permanent disk.
Instead of mounting volumes, you’ll want to use object storage like Riak CS
You’ll also want to handle app configuration via environment variables, so the platform can easily change them
We have this running today and I’ll shortly show you all a demo
Now we can run Docker images on our existing Garden-managed Linux cells with full native runtime support like logging, routing and health management
Second, the original Cloud Foundry DEA runtime was only focused on Linux workloads.
You need .NET applications on Windows?
How much of the architecture would I need to redo?
Turns out the major change to add Windows support is to implement a cell and Garden container backend in Windows. You can build a distribute .NET workloads as MSIs and have a Windows server provide the same logging, routing and health monitoring
Once the Garden backend can execute on Windows MSIs as workloads, the
Auctioneer can solicit bids for .NET workloads from Windows cells reps
Looking in terms of workflow, we offer a pool of cells that manage work. Developers just need to supply the source code or a deployable artifact and some metadata.
Each component becomes more specific as we go from task to recipe to container implementation.