Talk given at SpringOne 2015
The third platform, characterized by a fluid infrastructure where virtualized servers come into and out of existence, and workloads are constantly being moved about and scaled up and down to meet variable demand, calls for new design patterns, processes and even culture. One of the most well known descriptions of these new paradigms is the Twelve Factor App (12factor.net), which describes elements of cloud native applications. Many of these needs are squarely met through the Spring Framework, others require support from other systems. In this session we will examine each of the twelve factors and present how Spring, and platforms such as Cloud Foundry satisfy them, and in some cases we’ll even suggest that responsibility should shift from Spring to platforms. At the conclusion you will understand what is needed for cloud-native applications, why and how to deliver on those requirements.
Platforms have to make reasonable time assumptions when judging health, if you’re not started, what are you?
How:
Complete in flight requests, reject new ones.
Design for failure, mark jobs as complete, in progress, aborted etc.
Transactions, NACK
Service selection and consumption is a big part, can they handle sudden failure?
Be quick about it, you’re on a clock.
Cloud Native, resiliency is big. Healer processes.
Transition: So how do we do that?
Blue Green For this deploy.
This example is mysql
This example is mysql
Its better to declare our dependencies with our code
The upside, you’re deploys fail faster if the service can’t be found.
So to recap how that all works:
Demo
Head not to disposability, as we do blue green.
https://github.com/cdavisafc/twelvefactorapp/compare/f11_logs...f4_backing_services?expand=1
We made a change to our app, lets take a person name, and save who we greet
Controller change
https://github.com/cdavisafc/twelvefactorapp/blob/f4_backing_services/src/main/java/hello/HelloController.java#L29-L30
Added some config to our app for mysql, flyway and cloud foundry connectors.
https://github.com/cdavisafc/twelvefactorapp/blob/f4_backing_services/build.gradle#L40-L46
Cloud Native & 12 Factor apps are designed for continuous deployment
Why?
Important to emphasize
Dev has env just like
Acceptance and prod
(i.e. McKenty rant)
Cloud Native & 12 Factor apps are designed for continuous deployment
Why?
Dev, Acceptance, Prod
The services we use in dev are the services we use in prod – no tool gap
The data we use in dev is derived from prod
We don’t spend any time messing around with data conversions, it’s the same because it’s the same.
If every commit is a canidate, we desire to know that it works in our target environment.
We deploy, the same way to all environments (cf push)
We deploy the same thing, to all environments (war, from artifactory)
If every change is a candidate, there's no time gap, deployments are simple with low overhead, we design and build for continuous deployment. This is an architecture, design and mindset shift.
We minimize the personnel gap.
Developers have the tools (and the responsibility) to deploy and monitoring in production
Ops have the tools and the knowledge to deploy
Of the factors to pay attention too… pragmatism counts. The purist implementation w/ java is harder than the pragmatic one. Don’t take on that complexity until you need it.
https://github.com/cdavisafc/twelvefactorapp/compare/f4_backing_services...f12_admin_processes