VMware

In the session I went over why serverless is important to our industry, why server admins (which I then rephrased to SREs) are so important to our serverless success, and why stateless isn’t the answer for everything. Technology wise I’ll be “all over the map” talking about things like Knative and the VMware Event Broker Appliance, AWS Lambda, Akka Serverless

Is the emergence of new application platforms relevant to your enterprise? How will you benefit from scale-to-zero scenarios? What do “events” mean? In this session, I walked through these new patterns and present concrete, simple use cases and examples for each of them. We will also discuss the properties of platforms designed to support such patterns, as well as interesting and relevant innovations in the open-source community and the VMware ecosystem and portfolio.

For developers, Knative abstracts away complexity and enables them to focus on delivering value to their business. Can we make setting up a Kubernetes cluster and starting with Knative on your local machine even more straight forward than it is today? In this session, I focused on setting up a lightweight environment to help you build event-driven apps faster!

As developers, we all want to be more productive. Knative, a Kubernetes based platform to deploy and manage modern serverless works, helps to do just that. The idea behind Knative is to abstract away the complexity of building apps on top of Kubernetes as much as possible. How can you get Knative running on your local machine to try a few things out or even develop your apps? In this session, we ’ll look at setting up a Kubernetes cluster, installing Knative, and building an app.

With everything going on in DevOps, I think we can safely say that building pipelines is the way to deploy your applications to production. But knowing what you deploy to production and whether it is actually okay needs more data, like security checks, performance checks, and budget checks. We’ve come up with a process for that, which we call Continuous Verification “A process of querying external systems and using information from the response to make decisions to improve the development and deployment process.” In this session, we’ll look at extending an existing CI/CD pipeline with checks for security, performance, and cost to make a decision on whether we want to deploy our app or not.

In a nutshell, Continuous Verification comes down to making sure that DevOps teams put as many checks as possible into their CI/CD pipelines. These checks use external systems to validate the performance, security, and cost of your app without asking your engineers to do that manually. The systems that provide the data which decided whether your deployment goes to production or not, can also be used to help your engineers understand where the bottlenecks are in the process. With more checks in your automated pipeline, you have fewer manual tasks, less overhead, and better decisions to deploy to production or not. All that together means you get to spend more time at the beach!

At VMware we define Continuous Verification as:

“A process of querying external systems and using information from the response to make decisions to improve the development and deployment process.”

At #OSSDay, I got a chance to not only talk about what that means for serverless apps and how you can build it into your existing pipelines using tools like GitLab, CloudHealth, Wavefront and Gotling.

If you’ve read the blog posts on CloudJourney.io before, you’ve likely read the term “Continuous Verification”. If you haven’t that’s okay too. There’s an amazing article from Dan Illson and Bill Shetti on The New Stack explaining in detail what Continuous Verification is. In a nutshell, the Continuous Verification comes down to making sure that DevOps teams put as many checks as possible into their CI/CD pipelines. Adding checks into a pipeline means there are fewer manual tasks and that means you have access to more data tot smooth out and improve your development and deployment process.

So far we covered the tools and technologies, Continuous Integration, and Infrastructure as Code aspects of the ACME Serverless Fitness Shop. Now, it’s time to dive into observability!

If you’ve read the blog posts on CloudJourney.io before, you’ve likely read the term “Continuous Verification”. If you haven’t that’s okay too. There’s an amazing article from Dan Illson and Bill Shetti on The New Stack explaining in detail what Continuous Verification is. In a nutshell, the Continuous Verification comes down to making sure that DevOps teams put as many checks as possible into their CI/CD pipelines. Adding checks into a pipeline means there are fewer manual tasks and that means you have access to more data tot smooth out and improve your development and deployment process.

In part one we covered the tools and technologies and in part two we covered the Continuous Integration aspect of the ACME Serverless Fitness Shop. Now, it’s time to dive into Infrastructure as Code!

In a previous article, we looked at why developers should care about marketplaces to begin with. In that article, we spoke about how marketplaces accelerate time to market for apps by providing secure access to the components developers need to build world-class solutions. As the VMware teams build out the VMware Cloud Marketplace, we wanted to give you some insights into their journey to build the next-generation digital marketplace for all developers.