Innhold om Sky

Have you ever wanted to host a low traffic website in Azure, but required features like SSL and a custom domain? Were you disappointed when you found out that these features are only supported in the B1 App Service Plan for a whooping 50$ a month? With some simple changes and a Content Delivery Network (CDN) you can have it all for FREE!

At Digipost we are in the progress of building up our new infrastructure on Azure. We are already enthusiastic users of Terraform and have chosen to continue down that path, towards infrastructure-as-code (IaC) bliss, where the totality of your infrastructure can be created by a single command. But what happens when that totality is a bit big for a single Terraform state-file?

Companies and developers love the cloud. The cloud provides scalability and resilience to some of the most critical applications for a company. Due to the cloud, companies are no longer required to have large server installations on-premises. Actually, many companies are able to fully migrate almost all of their daily operations into the cloud. So, what are the downsides? Well, according to Info World, there are some major concerns regarding the cloud, one of them being costs. There are many ways to combat costs, and today I want to introduce you to one of my favorite ones, the spot market.

If you've read yesterdays post about ZEIT Now, you've already seen one of many approaches to develop and deploy a serverless API. In this post we will have a look at an alternative you can use to develop serverless applications, namely Serverless Framework. Serverless Framework can be used to develop, deploy and test your serverless applications targeted towards different cloud providers, or as they describe themselves: "The complete solution for building & operating serverless applications." Let's have a look on what this framework is all about.

By now, you have probably heard about serverless applications. You know, the applications where you focus on the code and let some third-party cloud provider manage the infrastructure and deployment process. With serverless functions offered by these cloud providers, it is surprisingly easy to create modular and serverless APIs that can easily be deployed with one command. Let's dig into how.

Do you want to run stateless container-based applications or microservices, but don't need all the features and management of a full-fledged Kubernetes cluster? Or do you crave the serverless model with no management and only-pay-what-you-use billing of other FaaS platforms, but find the runtime model and supported languages or versions too limiting? Let's have a look at Google Cloud Run - a fully managed serverless platform for running stateless HTTP-driven containers. And where you only pay for resources used when handling requests.

Feature toggling, or feature flags, is a fairly well known concept in the world of modern system development. It provides the foundation for separating launching a feature from the physical deployment of code, enabling things like A/B testing, piloting and a faster development process. With a few clicks, you can get going with a streamlined feature toggling setup in no time using hosted cloud services.

A typical cloud architecture - from a cloud native solution to a public cloud solution - consists of multiple connected services. Some of these services are your own, others are third-party services. Common for these is that they all communicate with each other over a network and that they depend on each other's availability. When your application integrates with another service - your application must handle erroneous behavior from the service. Thinking resilience is, based on my experience, something we developers often forget and is first addressed once we experience availability issues with the service in production.

This November, GitHub Actions moved to General Availability making another mark of GitHubs push towards eating more of the CI/CD ecosystem. In this article I'll show you how you can start testing your code directly in GitHub.

The Problem You’ve got your SPA, consisting of static CSS, HTML and JS, and high-performing microservices to provide the dynamic behavior of your app. The only thing remaining is hosting the static content somewhere, point a DNS to it, and call it a day. However, it turns out that your app needs a top menu, which is shared between all the apps in the organization, to provide a common look-and-feel and navigation. All of a sudden you’re pushed into the world of content transclusion, now loosely referred to as micro frontends

The dire second level consequences of choosing a private PaaS...

Have you ever deployed a static site, but found yourself in need of an API endpoint? Perhaps you needed somewhere to post form data, but the thought of setting up your own server, manage the endpoint and write the logic seemed like too much work. Not anymore