As operators role is evolving, the role of APIs, agile teams need agile infrastructure
TAS has created a secure, controlled, managed experience with that end in mind
We are seeing a continued evolution in the way that software teams run. We see a fundamental shift in the unit of work that teams perform from the ticket to the API. The introduction of devops and devsecops captures this movement. Relying on more intrinsically automatable infrastructure to deliver full LCM. Teams are able to get closer to their customers and deliver their work product as a living service supporting the business, vs a static unwieldy thing that is thrown over the wall at the business every quarter or once a year.
Here at VMware, we have worked with a number of teams through this transformation, and if you have been attending Spring One for a while you will likely . Each of these organizations has been successful in making this transition. If this isn’t your first Spring One, you have likely heard from these folks. Each of these organizations has been on this journey for a while, and I would like to talk through what has been core to their success as organizations. </craig>
Stephane Nicoll and Brian Clozel’s session on Spring Boot loves k8s
Deepa Kalani and Ramiro Salas’ session on Tanzu Service Mesh from the Developer’s Perspective
Alexey Nesterov and Gareth Clay’s session on Introducing Spring Cloud Gateway and API Hub for VMware Tanu
agile development requires agile, api driven infrastructure
One of the things that I find fascinating in talking to enterprises is working to really understand the effort associated with getting production code into environments. Teams spend too much time ‘engineering’ meaning the millions of tasks associated with setting up development, staging and in some cases production environments, sweating the details around how to operate the systems they are building and not enough time ‘developing’ -- capturing business logic in code to support the core business function.
We have made strong inroads into this historically through open source communities like the cloud foundry system. Superhighway from a developers IDE into a production environment.
Obviously I spend a lot of time talking about Kubernetes having worked on the project since day 1 and having spent a lot of time with real world organizations looking to bring . We are excited to bring that to the k8s ecosystem. And we’ve made a lot of progress in thoughtfully bringing this capability to establish the technology as a new IaaS substrate for the world. We are extremely excited at the possibility of using Kubernetes as a normalized IaaS that drives productivity, but in producing a more elegant experience for developers that don’t want to have to get into all the details of the IaaS world. It has been exciting to see the CF community embrace this and bring that superhighway for Spring applications to this emerging infrastructure world.
Taking a peek inside, the emerging implementation which is currently in Beta carries forwards the same constructs that CF developers know and love, but is snapping to programmable infrastructure primitives that represent the best of what open source communities looking to solve infrastructure problems can deliver.
To deliver those developer-centric experiences, however, has been a bit of an all-or-nothing bifurcation in the path until now… You either roll up the sleeves and build, configure, integrate, and manage everything yourself, or you’ve had something like Tanzu Application Service, which is a complete and integrated experience… but just like this sports car here is great for going fast, it’s not what you would take on a family camping trip, say, or a grocery run. In other words, if you want to get Spring microservices workloads to production in a hurry, TAS is a great way to do it… but if your workload didn’t fit the TAS model, you’ve been left with a lot of parts and pieces to try to build something to get that job done…
It’s a steep drop off, like the cliff face of our friend El Capitan here… The view is great from the top, but it doesn’t work for everybody
The vision here is simple. Offer developers the highest abstraction first. Ensure that the system offers up all the capabilities you need to get your spring app into pre-production and thence production environments, but ensure that if you have to leave the bounds of what an optinionated stack can offer, you don’t end up falling off that experiential cliff. Kubernetes was always intended as that goldilocks abstraction. High enough level to hide the specifics of a given infrastructure environment and offer up those API’s that devops teams need to create streamlined experiences, but low enough level that you don’t need to worry about the specifics of the environment that you are looking at.
The vision here is simple. Offer developers the highest abstraction first. Ensure that the system offers up all the capabilities you need to get your spring app into pre-production and thence production environments, but ensure that if you have to leave the bounds of what an optinionated stack can offer, you don’t end up falling off that experiential cliff. Kubernetes was always intended as that goldilocks abstraction. High enough level to hide the specifics of a given infrastructure environment and offer up those API’s that devops teams need to create streamlined experiences, but low enough level that you don’t need to worry about the specifics of the environment that you are looking at.
As we look to the future we see Tanzu as not only a simple super highway to production, but offers up the glue you need to build dev centric platforms that allows teams to focus more time on solving business problems without assuming that every team is the same and has the same precise needs.
The future is bright when you look at this world of more intrinsically agile infrastructure and what can be accomplished as the developer frameworks start to make full use of this.
Tanzu is the glue that makes it easier to build dev-centric platforms so that developers can focus up the stack.
(15:02) Tanzu Build Service is a great example of that kind of solution to a pervasive challenge to manage and secure the process of building containers as enterprises race to adopt Kubernetes and get to production early, often, and securely.
With the idea of modularity, composability, and genericization of capabilities we are extremely excited to announce the GA of Tanzu Build Service. This represents an important step on the path to creating operationalized services and offering value in worlds where the full CF experience doesn’t work for teams. Tanzu Build Service is a simple way to deterministically build apps from build packs, yielding container images that can be continuously patched with dependency updates and delivered into Kubernetes environments through the CD mechanism of your choice.
Functions are a great example of a different class of application that DevOps pros want to deliver a great developer experience for, but don’t want to have to build from scratch.
Challenges of running this class of applications has been hard from a resource perspective
As Sebastien showed us yesterday, the Spring team has been working with GraalVM to build native Spring Boot images, which change the economics of using Spring for serverless, scale-to-zero applications
Now, again, let’s look at the operator side of the equation… we’ll show the flow from local development to production running applications using assets in the Tanzu portfolio.