DEV Community: Marcus Rådell

"One size fits all"-services

Marcus Rådell — Mon, 12 Jun 2023 06:17:29 +0000

Most new projects seem to make an important architectural choice between deploying a microservice architecture or monolith. I will make the case that you should always follow some basic rules of microservices, and start with a monolith. I will call this setup "modular monolith".

Let's start to define a typical monolith before jumping into a modular monolith.

Layered architecture

A typical layered architecture will have global layers where the controllers have access to all the models which are in the layer below controllers.

Access to everything is pretty much the definition of the ball-of-mud architecture. Luckily, the layered architecture does reduce vertical access for any layer to only one additional layer below.

Monolith

When we change a small thing, we still deploy everything. And that deployment will be a single artifact.

If that is a good or bad thing will depend on your needs. In general, each infrastructure artifact involves some added complexity, so we want to keep the number of services deployed to a minimum. Monoliths is optimized for low complexity in your infrastructure.

Microservice

At a high level a microservice encapsulates its database schema (a set of database tables). Nobody outside of the service is allowed to query the database tables that belong.

Internally, it might not use layered architecture because the amount of code is less than in a monolith. Code architecture becomes optional as long as the amount of code stays small.

When a microservice is deployed, it is done so without affecting other services in the system. You can independently scale up a microservice's resources to handle more load. Microservices gives us more control over the infrastructure which we pay for in an increase in complexity.

Modular Monolith

If we imagine that we took a bunch of microservices, and merged them into a single server, that would give us a modular monolith.

Each service in our server would own its database schema, and to communicate between services, we always go through the service API. That usually means calling a method on an object and not doing a http call.

The overhead of managing each service is as small as in a traditional monolith. The encapsulation the same as in a microservice. As a bonus, you can move code around and change your service boundaries pretty fast. This makes the system simpler to change. Once the service boundaries are stable, you can try to promote a service into a microservice.

The main downside is that there is little documentation on how to write a modular monolith, and the team might drift towards a ball-of-mud layered architecture where they allow all services to query everything in the database. Having the mindset that you are doing microservices, but with one deployment, can help.

Shut up and take my image!

Marcus Rådell — Wed, 03 May 2023 19:07:29 +0000

If you have built your docker container image and want to deploy a web service, then you need to push your image up to some image repository. Think; GitHub for images.

I prefer github actions, and deploying each time we push to the main branch.

You might need to configure your cloud provider's image repository manually before pushing images to. For GCP, we need to create a Service Account manifest first (JSON content).

This is the part of my github action that pushes the image:

name: Push Image

on:
  push:
    branches:
      - "main"

  GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
  GCP_SA_KEY: ${{ secrets.GCP_SA_KEY }}
# Replace monadium with the name of your image.
IMAGE_URL: eu.gcr.io/${{ secrets.GCP_PROJECT_ID }}/monadium:${{ github.sha }}

jobs:
  ci:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2

      # This will change depending on your cloud provider. Main thing is that docker is configured to use the auth credentials from your cloud provider.
      - name: Setup GCP
        uses: google-github-actions/setup-gcloud@master
        with:
          project_id: ${{ env.GCP_PROJECT_ID }}
          service_account_key: ${{ env.GCP_SA_KEY }}
          export_default_credentials: true

      - name: Setup Docker For GCP
        run: |
          gcloud auth configure-docker -q

      # Build the application outside your docker image. Cargo build is Rust's build command. Change it to what your language requires.
      - name: Cargo Build
        run: cargo build --release

      # This will copy the built artefact(s) into the image.
      - name: Docker Build
        run: docker build -t $IMAGE_URL .

      # You can now push to the image repository.
      - name: Docker Push
        run: docker push $IMAGE_URL

There are a lot of other ways to push images, but I like the fact that most of this code works the same for all cloud providers, and usually works the same way locally if you need to debug.

Mother D*cker!

Marcus Rådell — Wed, 03 May 2023 18:33:25 +0000

If you want to use containers to deploy something to the cloud, here's a simple way to get started without feeling like a sinking ship.

0 Build your code outside of a container

You first need to find out how to build your code. You might generate a .dll, .jar, or a folder of .js files.

1 Copy the code into a container image

Find a good base image to use to run your code.
Copy the built content into your container.
Expose the right port for your web server.
Set the command that starts the web server.

Here's a Dockerfile example for C# .NET v7:

FROM mcr.microsoft.com/dotnet/aspnet:7.0
WORKDIR /app
COPY published/ ./

EXPOSE 5182

ENTRYPOINT ["dotnet", "LabApi.dll"]

This will work across architectures for many languages, but not all. If it doesn't work locally, then it can still work in your CI/CD of choice, like GitHub Actions. And that's the only thing you need to get started!

Oh shit, git!

Marcus Rådell — Wed, 03 May 2023 17:55:52 +0000

Here's a quick tip to get back on track if you ever get stuck as a beginner:

0 Quick save

Copy your local repo folder to somewhere else. Worst case, and you can restore everything.

1 Resetting

Assuming you are on the main branch; git add . && git reset --hard origin/main will remove all local file changes and reset your main branch.