Talks

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!

Whether you’re a Product Manager or Developer Advocate, once you start you think that every presentation has to be unique… spoiler alert, it doesn’t have to be

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.

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 Serverless Nashville, I got a chance to not only talk about what that means for serverless apps but also how we use serverless in some of the business units at VMware.

One of my strong beliefs is that coding should be available to everyone. Whether that is a seasoned developer or someone who just wants to connect two systems together. With Project Flogo, we’ve made it possible for everyone to use the same constructs. If you want to use the web-based flow designer, that’s awesome! If you want to write your apps using the Go API, that’s awesome too. In this podcast I joined Jan Oberhauser (N8N), Nick O’Leary (Node Red), and the SAP Customer Experience Labs team to discuss No Code / Low Code.

As a developer, I always thought that security, like documentation, would be done by someone else. While that might have been true in the past, in today’s world that model no longer works. As a developer you’re responsible for the security of your app. Security in this case should be seen in the broadest sense of the word, ranging from licenses to software packages. A chef creating cheesecake has similar challenges. The ingredients of a cheesecake are similar to the software packages a developer uses. The preparation is similar to the DevOps pipeline, and recipe is similar to the licenses for developers. Messing up any of those means you have a messy kitchen, or a data breach!

Trusting Your Ingredients - What Building Go Apps And Cheesecake Have In Common.

In this lightning session at GopherCon 2019, I got the chance to talk about two things I love. Cheesecake and Golang! As a developer, I’ve written code and built apps, and I realized that building apps and creating a cheesecake have a lot in common. In both cases you need to have the right ingredients, you need to trust your suppliers and have transparency in your production process. In this talk, we’ll look at how you can, and why you should, know what is in the app you deploy.

Go modules are here to stay and it’s about time to start modularizing your code. During the meetup at the Go UserGroup in Atlanta we spoke about:

• What Go modules are and why you need them
• The benefits are of using modules
• The differences between modules and the things we did before that
• What you need to do to “switch” to modules.

Go modules are here to stay and I got the chance to talk to the Atlanta chapter of Woman Who Go on what Go modules are and how you can switch to use them.