In our second post about serverless, we’ll discuss some broader issues. Again, we’re not trying to be prescriptive. We want to bring up points that will foster discussions among all the stakeholders. Many people who say that all applications will be serverless haven’t run their applications at scale and haven’t solved all of the problems regarding latency, complexity, and vendor lock-in. That’s what we’re going to talk about here.
Many developers say that serverless is the future of computing, while others say that it will never be successful. Our own opinion is less polarized. We see serverless as an option, one possible stepping stone on the journey from startup to a midsize company, to a large enterprise. In these two blog posts, we’ll discuss how serverless fits into that journey, what we see as its strong points, as well as its drawbacks.
In the first article in this series, we gave you some questions to help you and others at your company decide if Kubernetes is right for you. In this post, we’ll give you an example of where Kubernetes can be a good fit.
When you’re considering whether or not to implement Kubernetes, perhaps the first question to ask yourself is do you need it at all?
The point of any technology isn’t the technology itself. When done right, Kubernetes can reduce the barrier of entry for application developers so they can get features from their machines to your customers as quickly and easily as possible. But do you already have a solution that works well? If you do, why do you want to change it? Making such a radical change in your technology is potentially quite dangerous so what’s your motivation?
It very well might be that sticking with and improving the solution you already have offers a better cost/benefit tradeoff. It’s easy to fall into the trap of believing that simply adopting a new technology like Kubernetes will instantly solve your hard organizational or technical problems, however, we know that is seldom true.
In this blog post we’ll share some tips and tricks for evaluating your own situation to see if Kubernetes is a good fit. We’ve learned these from helping hundreds of customers adopt Kubernetes — in addition to not, when there was a better solution available. We’ll see that the question isn’t that simple to answer and there are a lot of variables to consider. In the next blog post, we’ll talk about a situation where Kubernetes can be a good fit and how to start your first Kubernetes project.
Note that these blog posts assume you already have some familiarity with Kubernetes. If you are just starting to learn, our Getting Started with Kubernetes blog series is a good place to start.
As Kubernetes grows in popularity, the number of options for Kubernetes users continues to increase. Providers of managed Kubernetes offerings will often learn lessons about operating large numbers of clusters at scale; it’s increasingly common that they will contribute this knowledge back to the ecosystem, allowing those organizations who need more control and flexibility to reap the benefits.
With the announcement of the Amazon EKS Distro during AWS re:Invent, the Amazon EKS team has contributed back to the cloud-native community in a big way. In this post, we’ll take a brief look at what the Amazon EKS Distro is, explore why you might choose this over current managed service offerings and finally, explore how you can get started with the Amazon EKS Distro on day 1 using Pulumi.
One of the most exciting aspects of using Pulumi can also present some interesting engineering challenges. Pulumi supports three operating systems, multiple programming languages, and almost 40 different providers. This means creating tooling that works effortlessly across all possible user scenarios can often throw unexpected challenges our way.
Nowhere are these challenges more prevalent than in the Pulumi Docker containers.
The pulumi/pulumi Docker container is almost 3Gb uncompressed, which is generally considered large for a Docker image. In this post, I’ll examine why this container has grown to the size that it is, and talk about how we hope to solve it.
The secrets in your infrastructure are a vital part of your security model, and provisioning infrastructure is an inherently privileged process. Previously we introduced secret encryption and started encrypting secret configuration values inside the Pulumi state so that users could be confident their passwords, tokens, and other secret values were viewable only by them while managing their infrastructure. Our first iteration of the encryption used either a passphrase for encrypting the secret or encryption via the Pulumi service backend. However, these options didn’t meet the needs of our users who needed more control over their data. That’s why we also added support for “Cloud Secret Providers,” giving users full confidence that their sensitive values are for their eyes only.