Build a globally resilient architecture with Azure Load Balancer

Azure Load Balancer’s global tier is a cloud-native global network load balancing solution. With cross-region Load Balancer, customers can distribute traffic across multiple Azure regions with ultra-low latency and high performance. To better understand the use case of Azure’s cross-region Load Balancer, let’s dive deeper into a customer scenario. In this blog, we’ll learn about a customer, their use case, and how Azure Load Balancer came to the rescue.

Who can benefit from Azure Load Balancer?

This example customer is a software vendor in the automotive industry. Their current product offerings are cloud–based software, focused on helping vehicle dealerships manage all aspects of their business including sales leads, vehicles, and customer accounts. While it is a global company, most of its business is done in Europe, the United Kingdom (UK), and Asia Pacific regions. To support its global business, the customer utilizes a wide range of Azure services including virtual machines (VMs), a variety of platform as a service (PaaS) solutions, Load Balancer, and MySQL to help meet an ever-growing demand.

What are the current global load balancing solutions?

The customer is using domain name service (DNS)–based traffic distribution to direct traffic to multiple Azure regions. At each Azure region, they deploy regional Azure Load Balancers to distribute traffic across a set of virtual machines. However, if a region went down, they experienced downtime due to DNS caching. Although minimal, this was not a risk they could continue to take on as their business expanded globally.

What are the problems with the current solutions?

Since the customer’s solution is global, as traffic increased, they noticed high latency when requesting information from their endpoints across regions. For example, users located in Africa noticed high latency when they tried to request information. Often their requests were routed to an Azure region on another continent, which caused the high latency. Answering requests with low latency is a critical business requirement to ensure business continuity. As a result, they needed a solution that withstood regional failover, while simultaneously providing ultra-low latency with high performance.

How did Azure’s cross-region Load Balancer help?

Given that low latency is a requirement for the customer, a global layer 4 load balancer was a perfect solution to the problem. The customer deployed Azure’s cross-region Load Balancer, giving them a single unique globally anycast IP to load balance across their regional offices. With Azure’s cross-region Load Balancer, traffic is distributed to the closest region, ensuring low latency when using the service. For example, if a customer connected from Asia Pacific regions, traffic is automatically routed to the closest region, in this case Southeast Asia. The customer was able to add all their regional load balancers to the backend of the cross-region Load Balancer and thus improved latency without any additional downtime. Before the update was deployed across all regions, the customer verified that their metrics for data path availability and health probe status are 100 percent on both its cross-region Load Balancer and each regional Load Balancer.
 

After deploying cross-region Load Balancer, traffic is now distributed with ultra-low latency across regions. Since the cross-region Load Balancer is a network load balancer, only the TCP/UDP headers are quickly inspected instead of the entire packet. In addition, the cross-region Load Balancer will send traffic to the closest participating Azure region to a client. These benefits are seen by the customer who now sees traffic being served with lower latency than before.

Learn More

Visit the Cross-region load balancer overview to learn more about Azure’s cross-region Load Balancer and how it can fit into your architecture.
Quelle: Azure

Developing Go Apps With Docker

Go (or Golang) is one of the most loved and wanted programming languages, according to Stack Overflow’s 2022 Developer Survey. Thanks to its smaller binary sizes vs. many other languages, developers often use Go for containerized application development. 

Mohammad Quanit explored the connection between Docker and Go during his Community All-Hands session. Mohammad shared how to Dockerize a basic Go application while exploring each core component involved in the process: 

Follow along as we dive into these containerization steps. We’ll explore using a Go application with an HTTP web server — plus key best practices, optimization tips, and ways to bolster security. 

Go application components

Creating a full-fledged Go application requires you to create some Go-specific components. These are essential to many Go projects, and the containerization process relies equally heavily on them. Let’s take a closer look at those now. 

Using main.go and go.mod

Mohammad mainly highlights the main.go file since you can’t run an app without executable code. In Mohammad’s case, he created a simple web server with two unique routes: an I/O format with print functionality, and one that returns the current time.

What’s nice about Mohammad’s example is that it isn’t too lengthy or complex. You can emulate this while creating your own web server or use it as a stepping stone for more customization.

Note: You might also use a package main in place of a main.go file. You don’t explicitly need main.go specified for a web server — since you can name the file anything you want — but you do need a func main () defined within your code. This exists in our sample above.

We always recommend confirming that your code works as expected. Enter the command go run main.go to spin up your application. You can alternatively replace main.go with your file’s specific name. Then, open your browser and visit http://localhost:8081 to view your “Hello World” message or equivalent. Since we have two routes, navigating to http://localhost:8081/time displays the current time thanks to Mohammad’s second function. 

Next, we have the go.mod file. You’ll use this as a root file for your Go packages, module path for imports (shown above), and for dependency requirements. Go modules also help you choose a directory for your project code. 

With these two pieces in place, you’re ready to create your Dockerfile! 

Creating your Dockerfile

Building and deploying your Dockerized Go application means starting with a software image. While you can pull this directly from Docker Hub (using the CLI), beginning with a Dockerfile gives you more configuration flexibility. 

You can create this file within your favorite editor, like VS Code. We recommend VS Code since it supports the official Docker extension. This extension supports debugging, autocompletion, and easy project file navigation. 

Choosing a base image and including your application code is pretty straightforward. Since Mohammad is using Go, he kicked off his Dockerfile by specifying the golang Docker Official Image as a parent image. Docker will build your final container image from this. 

You can choose whatever version you’d like, but a pinned version like golang:1.19.2-bullseye is both stable and slim. Newer image versions like these are also safe from October 2022’s Text4Shell vulnerability. 

You’ll also need to do the following within your Dockerfile: 

Include an app directory for your source codeCopy everything from the root directory into your app directoryCopy your Go files into your app directory and install dependenciesBuild your app with configurationTell your Docker container to listen on a certain port at runtimeDefine an executable command that runs once your container starts

With these points in mind, here’s how Mohammad structured his basic Dockerfile:

# Specifies a parent image
FROM golang:1.19.2-bullseye

# Creates an app directory to hold your app’s source code
WORKDIR /app

# Copies everything from your root directory into /app
COPY . .

# Installs Go dependencies
RUN go mod download

# Builds your app with optional configuration
RUN go build -o /godocker

# Tells Docker which network port your container listens on
EXPOSE 8080

# Specifies the executable command that runs when the container starts
CMD [ “/godocker” ]

From here, you can run a quick CLI command to build your image from this file: 

docker build –rm -t [YOUR IMAGE NAME]:alpha .

This creates an image while removing any intermediate containers created with each image layer (or step) throughout the build process. You’re also tagging your image with a name for easier reference later on. 

Confirm that Docker built your image successfully by running the docker image ls command:

If you’ve already pulled or built images in the past and kept them, they’ll also appear in your CLI output. However, you can see Mohammad’s go-docker image listed at the top since it’s the most recent. 

Making changes for production workloads

What if you want to account for code or dependency changes that’ll inevitably occur with a production Go application? You’ll need to tweak your original Dockerfile and add some instructions, according to Mohammad, so that changes are visible and the build process succeeds:

FROM golang:1.19.2-bullseye

WORKDIR /app

# Effectively tracks changes within your go.mod file
COPY go.mod .

RUN go mod download

# Copies your source code into the app directory
COPY main.go .

RUN go mod -o /godocker

EXPOSE 8080

CMD [ “/godocker” ]

After making those changes, you’ll want to run the same docker build and docker image ls commands. Now, it’s time to run your new image! Enter the following command to start a container from your image: 

docker run -d -p 8080:8081 –name go-docker-app [YOUR IMAGE NAME]:alpha

Confirm that this worked by entering the docker ps command, which generates a list of your containers. If you have Docker Desktop installed, you can also visit the Containers tab from the Docker Dashboard and locate your new container in the list. This also applies to your image builds — instead using the Images tab. 

Congratulations! By tracing Mohammad’s steps, you’ve successfully containerized a functioning Go application. 

Best practices and optimizations

While our Go application gets the job done, Mohammad’s final image is pretty large at 913MB. The client (or end user) shouldn’t have to download such a hefty file. 

Mohammad recommends using a multi-stage build to only copy forward the components you need between image layers. Although we start with a golang:version as a builder image, defining a second build stage and choosing a slim alternative like alpine helps reduce image size. You can watch his step-by-step approach to tackling this. 

This is beneficial and common across numerous use cases. However, you can take things a step further by using FROM scratch in your multi-stage builds. This empty file is the smallest we offer and accepts static binaries as executables — making it perfect for Go application development. 

You can learn more about our scratch image on Docker Hub. Despite being on Hub, you can only add scratch directly into your Dockerfile instead of pulling it. 

Develop your Go application today

Mohammad Quanit outlined some user-friendly development workflows that can benefit both newer and experienced Go users. By following his steps and best practices, it’s possible to create cross-platform Go apps that are slim and performant. Docker and Go inherently mesh well together, and we also encourage you to explore what’s possible through containerization. 

Want to learn more?

Check out our Go language-specific guide.Read about the golang Docker Official Image.See Go in action alongside other technologies in our Awesome Compose repo.Dig deeper into Dockerfile fundamentals and best practices.Understand how to use Go-based server technologies like Caddy 2.
Quelle: https://blog.docker.com/feed/

AWS Global Accelerator kündigt AddEndpoints- und RemoveEndpoints-APIs an

AWS Global Accelerator bietet jetzt zwei neue APIs, AddEndpoints und RemoveEndpoints, mit denen Sie Endpunkte hinter Ihrem Accelerator hinzufügen und entfernen können. Mit diesen neuen APIs können Sie jetzt Endpunkte hinter Ihren Accelerators konfigurieren, ohne zum Hinzufügen oder Entfernen von Endpunkten die vollständige Liste der Endpunkte angeben zu müssen. Sowohl die AddEndpoints- als auch die RemoveEndpoints-API kann bis zu zehn Endpunkte in einem einzigen API-Aufruf enthalten. Die neuen APIs tragen zu mehr Skalierbarkeit und weniger Fehlern bei der Verwaltung Ihrer Endpunkt-Workflows mit Global Accelerator bei. Sie können weiterhin die AddEndpointGroup und RemoveEndpointGroup APIs verwenden, um Endpunktgruppen hinzuzufügen und zu entfernen, und mit der DescribeEndpointGroup API können Sie alle Endpunkte hinter einem Accelerator beschreiben.
Quelle: aws.amazon.com

Amazon Aurora unterstützt jetzt T4g-Instances in AWS GovCloud (USA)-Regionen

Amazon Aurora unterstützt jetzt AWS Graviton2-basierte T4g-Datenbank-Instances in den AWS GovCloud (USA)-Regionen. T4g-Datenbank-Instances bieten eine Leistungsverbesserung von bis zu 49 % gegenüber vergleichbaren x86-basierten Datenbank-Instances der aktuellen Generation. Sie können diese Datenbank-Instances starten, wenn Sie Amazon Aurora MySQL-Compatible Edition und Amazon Aurora PostgreSQL-Compatible Edition verwenden.
Quelle: aws.amazon.com

AWS Batch erhöht die Rechen- und Speicherressourcenkonfigurationen für Aufträge vom Fargate-Typ um das Vierfache

AWS Batch-Kunden können jetzt Aufträge mit Fargate-Typ einreichen, um bis zu 16 vCPUs zu verwenden, was einer etwa vierfachen Steigerung gegenüber früher entspricht. vCPUs sind die primäre Rechenressource in Batch-Aufträgen mit Fargate-Typ. Eine höhere Anzahl an vCPUs ermöglicht es rechenintensiven Anwendungen wie Machine-Learning-Inferenz, wissenschaftlicher Modellierung und verteilter Analytik, leichter auf Fargate ausgeführt zu werden. Darüber hinaus können Kunden nun bis zu 120 GiB Speicher für Fargate-Aufträge bereitstellen, was ebenfalls einer vierfachen Steigerung gegenüber früher entspricht. Dies hilft ihren Batch-Aufträgen, speicherintensive Operationen auf Fargate besser durchzuführen. Größere vCPU- und Speicheroptionen können auch die Migration zu Serverless-Container-Computing für Aufträge vereinfachen, die mehr Rechenressourcen benötigen und nicht einfach in kleinere Container umgestaltet werden können.
Quelle: aws.amazon.com

Amazon EBS Snapshots Archive ist jetzt in AWS GovCloud (USA)-Regionen verfügbar, s dass Kunden bis zu 75 % der Kosten für Snapshot-Speicher sparen können

Mit Amazon Elastic Block Store (EBS) Snapshots Archive können Kunden bis zu 75 % der Speicherkosten für Amazon EBS Snapshots einsparen, auf die sie selten zugreifen und die sie länger als 90 Tage aufbewahren möchten. Amazon EBS-Snapshots sind inkrementell. Es werden nur die Änderungen seit dem letzten Snapshot gespeichert. Dies macht sie kostengünstig für tägliche und wöchentliche Backups, auf die häufig zugegriffen werden muss. Sie können Amazon EBS Snapshot Archive für Snapshots verwenden, auf die Sie alle paar Monate oder Jahre zugreifen und aus rechtlichen oder Compliance-Gründen langfristig aufbewahren möchten. Dadurch speichern Sie vollständige zeitpunktbezogene Snapshots zu niedrigeren Kosten, als dies bei der Speicherung auf der Standardstufe der Fall wäre. Sie können auch Amazon Data Lifecycle Manager verwenden, um Snapshots zu erstellen und sie automatisch basierend auf Ihren spezifischen Richtlinien zu EBS Snapshots Archive verschieben, wodurch die Notwendigkeit der Verwaltung komplexer benutzerdefinierter Skripte und das Risiko unbeaufsichtigter Speicherkosten weiter reduziert wird. 
Quelle: aws.amazon.com

Amazon Cognito bietet jetzt einen Löschschutz für Benutzerpools

Sie können nun den Löschschutz für Ihre Amazon Cognito Benutzerpools aktivieren. Wenn Sie einen Benutzerpool mit Löschschutz konfigurieren, kann der Pool von keinem Benutzer gelöscht werden. Der Löschschutz ist jetzt standardmäßig für neue, über die AWS-Konsole erstellte Benutzerpools aktiviert. Sie können den Löschschutz für einen bestehenden Benutzerpool in der AWS-Konsole, der AWS-Befehlszeilenschnittstelle und der API aktivieren oder deaktivieren. Der Löschschutz verhindert, dass Sie die Löschung eines Benutzerpools beantragen können, es sei denn, Sie ändern den Pool zuerst und deaktivieren den Löschschutz.
Quelle: aws.amazon.com