Cloud-Native

So far we've covered infrastructure, the serverless shop, and CICD. But how do you know what's going on in your code and your infrastructure? That's where observability comes into the picture. We'll dive into using Wavefront to see what's going on.

Building the infrastructure to run the ACME Serverless Fitness Shop is just as important as the shop itself. With Infrastructure as Code, you can program your cloud environment whether they're containers, VMs, or functions.

In part one of the series on the ACME Serverless Fitness Shop, we've gone over the tools and technologies. Now, it's time to dive into the depths. Let's check out how CircleCI plays an important role in the lifecycle of the shop and how continuous verification works in serverless apps!

What choices do you need to think about when moving to serverless? How can you use Continuous Verification with serverless? We'll dive into that and more in our series on building the ACME Serverless Fitness Shop. First up, choosing the tools and technology.

Microservices and serverless give us as developers an incredible amount of freedom. We can choose our language and we can decide where and when to deploy our service. One of the biggest challenges, though, is figuring out how things go wrong and how to fix it.

This post examines the process of refactoring a simple microservice, with an example pulled from recent work

The CTO of a company I have worked for used to say that services should be loosely coupled but tightly integrated. I didn’t realize until a lot later how true that statement is as you’re building out microservices. How those microservices communicate with each other has also changed quite a bit. More often than not, they send messages using asynchronous protocols. As an industry, we decided that this new way of building apps should be called “Event-Driven Architecture (EDA).

In managing applications deployed on Kubernetes, developers have a significant number of options to choose from. These options cover both open source, and commercial options and cover three main categories: Metrics — are a numeric representation of data measured over intervals of time. And you can use mathematical modeling and prediction to derive the behavior of the system over an internal of time - either present or the future. Hence, metrics are useful for monitoring but more powerful when enabled with analysis mechanisms such as correlation and anomaly detection.

How are applications packaged for use in a Kubernetes environment? This post looks at two of the most common methods, a

Before I get started, I’d like to give special thanks to two of my colleagues at VMware, Duffie Cooley and Scott Lowe of the Kubernetes Architecture team for helping me think through and better understand this subject. I’d highly recommend following both for their thoughts on cloud native architectures and Kubernetes. Services are one of the most commonly configured and used configuration object in Kubernetes. Through I used them frequently as I was learning how to use Kubernetes, I found recently that I didn’t understand how services interacted with the other objects within a Kubernetes cluster.