With declarative infrastructure, what you define is what gets set up on your system. When software engineers use Helm, the package manager for Kubernetes, in building a Cloud Native system, they tend to believe that specifying a value.yaml file is being ‘declarative.’

Moving your business to the cloud could mean freeing your organisation from the need to maintain your own antiquated, energy-sucking data centres for everything. Escaping the ever-present threat that a problem in one part of your system could cripple the whole thing. Recruiting—and keeping— smart engineers eager to work with the latest technology.

In a previous post we covered the history and rules behind capabilities. In this post, we'll go through some examples of how Linux capabilities work and can be used, and the tooling available. We will also take a look at why capabilities are important when working with containers.

As Container Solutions grows, so does the number of projects we commit to every year. To keep quality high and continue to serve our clients well, we have learned to streamline the way we deliver our services.

I’d like to share with you the architecture and programming pattern we've been using to build Cloud Native applications. The use case I'm going to present is a RESTful application deployed on AWS, using AWS API Gateway and AWS Lambda. I want to show how by adopting specific AWS components and programming paradigms, we can increase the reliability of the applications we write, while also improving their maintainability.