Next.js is a really exciting framework that makes it simple to build React applications with excellent features that you’d expect in production. I won’t go into much detail here, as the Next.js documentation does that brilliantly, but one of the key things that stood out is the easy development experience.
By using create-next-app you can immediately get set up with an interactive dev experience that auto-reloads code changes in your browser as you make changes. Next.js also has support for building web APIs without needing any separate API server (e.g, ASP.NET Core, Go’s net/http package). …
Having attended the last two European KubeCon events (2018 and 2019), it’s become increasingly obvious that operators are becoming a hot topic within the community.
I also had the pleasure of attending the Operator Framework Workshop session delivered by Red Hat. This was an excellent session which covered the basics of Operators and how to create them using the Operator Framework.
The CoreOS documentation does an excellent job of explaining this, so I’ll only try and summarise it here. …
A while ago, we posted a blog discussing “How we develop apps that rely on databases in a Kubernetes workflow”.
In that post, we discussed the different pains we’ve experienced when it comes to developing with databases. Unsurprisingly, the key issue was around state.
When I switch branches, my code flips immediately to the version I want to be working against. Unfortunately, the database I’m developing against might still include schema or data changes from the original branch which might conflict with the code on my new branch.
Furthermore, I want to get confidence that the changes I’m making in development won’t cause issues in production. To do that, a production-like dataset in development is ideal. Unfortunately, that might be very large and it might not be possible to hold all the data on my machine, or it takes too long to get a copy of that myself. Often, the workaround is to use shared database instances, at which point I may start to trip over unrelated changes my colleagues are making to the database! …
Recently, our team has switched to using Kubernetes for all of our hosted services. There are many reasons we decided to start using Kubernetes, but here’s a few of them:
Furthermore, containerising our applications made us think very carefully about dividing up our application into microservices that are all stateless. This means they can be easily scaled or replaced by Kubernetes without downtime. Stateless code is great, but it’s likely you’ll end up needing to store state somewhere, and that traditionally takes shape as a database. …
In our first Kubernetes blog post, we discussed what Kubernetes has to offer and why you might want to use it.
To go with that blog, we started a series of walk-throughs on github on how to build an application using Kubernetes.
We’ve just released the latest walk-through in this series, which discusses deploying an application using Helm. This post is going to talk about why we chose to use Helm. It references the previous walk-throughs in the Kubernetes series, so if you haven’t read them yet it might not make sense. (Click here to check them out!)
In the first four episodes in our Kubernetes series, we deployed our application using