There’s no doubt that the main skill of any software developer is to write good code regardless of the programming language and the platform he is specialized on. Besides this fundamental set of skills there’s an additional one which is oftentimes overlooked or undervalued by many developers.

In the past years I've worked with various clients to migrate existing workloads to the cloud and to build new ones in a cloud-native fashion. Most of the time the main goal for those projects was to reduce costs. However, in my opinion there's just one reason for any business to leverage the cloud.

One of the fundamental characteristics of the cloud is metered billing: You only pay for what you actually use. However, this makes it kind of unpredictable what you are charged at the end of the month. AWS Budgets help you to keep an eye on your spending and getting notified once you exceed pre-defined thresholds.

In previous blog posts I’ve shown how to build serverless microservices which provide a REST API. Each service consists of a bunch of Lambda functions triggered by the AWS API Gateway. In a real world scenario multiple microservices would compose an application exposed through a single domain. To achieve this, a custom domain can be used.

It’s not uncommon to work with external systems from within a Lambda function: databases, web services, legacy systems, etc. Oftentimes it is necessary to authenticate against these systems via API keys or actual usernames and passwords. Now the questions is how to securely handle these secrets.

It's a best practice to launch servers into private subnets so that they are not available from the public internet. But how can they be easily accessed in case of some administrative task? This is where a so-called bastion host comes in. This blog post shows how to launch a bastion host and how to use it.

A Virtual Private Cloud (VPC) is one of the basic building blocks you need when running workloads on infrastructure in AWS. There are some best practices that should be followed when setting up a VPC which are outlined in this blog post.

When it comes to migrating applications to the cloud or building new Cloud-native applications the traditional mindset regarding a fear of vendor lock-in must be overcome. Instead, the focus should be shifted to the question how the usage of the services offered by cloud providers can be utilized to create value for the business and therefore helps in getting an edge over the competition.

GitHub provides a simple API for updating the status of commits based on the results of Continuous Integration (CI) builds. This can easily be integrated with AWS CodePipeline which has no out-of-the-box support for this feature.

The OpenAPI Specification (aka Swagger) provides a structured way for describing REST APIs. The AWS API Gateway can be configured based on this Swagger configuration files. This way the configuration of the API can be done in "code", can be automated completely and from the configuration the documentation can be generated.

Automation is king! In this blog post I show how simple it is to setup a CI/CD pipeline for automatically building and deploying Serverless applications based on SAM running on AWS.

Most of the time I've been using Node.js for building Lambda functions running on AWS. Recently, I wanted to experiment with Java for building a serverless application. In this blog post I describe the necessary steps for building a very simple microservice.

Building microservices based on serverless platform services provided by public cloud providers is pretty easy. However, there seems to be no real recommendations how to set up and manage bigger codebases. In this post I'll explain how we decided to structure a project when we started working on a serverless backend API in one of our client projects.

It's easy to set up a build pipeline to automatically publish your Jekyll site whenever you push new content to your git repository. This way you are able to automate this whole process.

Hosting static websites by combining managed services offered by AWS provides a solution with almost no operations overhead at very low cost. Furthermore, no additional work is required to make it fault-tolerant and scalable. This post shows how the setup can be completely automated to get started in literally a couple of minutes.

Basic authentication can be added pretty easily to CloudFront distributions using a simple Lambda@Edge function. This opens up the possibility to restrict access to static websites hosted with AWS S3.