Background

Recently, I had to work on a Python project that depended on some libraries which appear to only work on X86_64 machines, I came across Colima during my struggles with getting oracle-xe containers to work on my machine and settled completely with it after this episode of failing to run X86_64 dev containers with Docker Desktop.

Hello Colima,

Colima, literally meaning Containers in Linux on macOS is a container runtime with minimal setup. it boasts several awesome features, including the ability to run multiple Linux instances, support for both docker and container runtimes and lightweight Kubernetes clusters powered by k3s.

I settled for Colima due to the following reasons;

1. Support for everything I get from Docker Desktop (I don't use Docker extensions, although I got the lead from oracle-xe from a Docker desktop plugin)

2. QEMU-powered X86_64 emulation for the X86_64 runtime (may be slow, but has better compatibility than the Rosetta-based emulation in Docker Desktop).

3. Run two or more docker runtimes at the same time (I prefer to continue running my arm native tools in an arm-based docker instance).

4. Spin up a k3s Kubernetes cluster the easiest way.

Docker Contexts

Docker Contexts is a Docker CLI feature that enables a single Docker CLI installation to manage multiple Docker hosts, swarm clusters, and even Kubernetes clusters.

Colima rides on this feature to provide great features like running multiple Linux instances on a single machine and using docker context, you can easily switch, and manage container deployments across several docker instances, including instances not managed by Colima (e.g Docker Desktop).

VS Code Dev Containers

For developers who do not like clogging their dev machines with all the tools, Development Container (or Dev Container for short) allows you to use a container as a full-featured development environment. It can be used to run an application, to separate tools, libraries, or runtimes needed for working with a codebase, and to aid in continuous integration and testing. Dev containers can be run locally or remotely, in a private or public cloud.

Visual Studio Code has the VS Code Dev Container plugin that simplifies the process to spin up development containers right within the editor. While it has support for most CPU architecture, it derives the instantiated container architecture based on the OS architecture of the active Docker context.

This means that to run an X86_64 devcontainer, you need to ensure that the active Docker context is based on the X86_64 architecture. This can be verified by doing the following:

# start X86_64 container in colima (skip if you already have an X86_64 docker instance)
colima start --arch x86_64 -p qemu

# review available docker contexts
docker context list

# switch active docker context to an X86_64 instance (colima instances are always prefixed with 'colima-'
docker context use colima-qemu

You can easily switch back to any other context, once the devcontainer is running.

Conclusion

Using this approach, we can successfully run X86_64 (aka AMD64) development workloads on Apple Silicon without spinning up a full-fledged virtual machine.

Maybe this approach can be used to achieve the reverse (ARM64 workloads on X86_64 machines), I am not sure, but it may one day be worth the try for me.

TinySaas culminated from my work in migrating an ASP.NET legacy application to ASP.NET Core.

Why TinySaas?

There abound on the internet several frameworks that aim to allow developers to build multitenant applications using the .NET Core Framework, but the keyword (Framework).

TinySaas is a library that aims to add multitenancy support to new and existing ASP.NET Core applications without forcing the adoption of a new framework.

The credit for this library goes to Gunnar and Michael, two great authors whose several blog articles on this topic served as the foundation for this simple library.

Getting Started

Multitenancy support should not require a rewrite nor massive changes. With TinyTenant, you can now add multitenancy support to both new and existing projects in simple steps.

1. Add CodEaisy.TinySaas.AspNetCore to your application via Nuget or the .NET CLI

dotnet add package CodEaisy.TinySaas.AspNetCore --version 1.0.0

1. In Startup.cs, add the following inside the ConfigureServices method.

    public void ConfigureServices(IServiceCollection services)
    {
        // register all global singleton services here, and also dependencies for your TenantStore and ResolutionStrategy if any
   
        // ...
   
        // OPTION 1
        services.AddMultiTenancy<Tenant, TenantStore<Tenant>, TenantResolutionStrategy>();
   
        // OPTION 2
        // uses default `CodEaisy.TinySaas.Model.TinyTenant` as tenant model
        services.AddMultiTenancy<TenantStore<TinyTenant>, TenantResolutionStrategy>();
   
        // ...
   
        // services.AddControllers();
    }
   

   Then, add the following in the Configure method.

   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
      if (env.IsDevelopment())
      {
          app.UseDeveloperExceptionPage();
      }
   
      // enable multitenant support, with missing tenant handler and tenant container
   
      // OPTION 1
      // missing tenant handler has a dependency that can be provided immediately
      app.UseMultitenancy<Tenant, MissingTenantHandler, MissingTenantOptions>(missingTenantOptions);
   
      // OPTION 2
      // missing tenant handler does not have a dependency or dependency is already registered in services
      app.UseMultitenancy<Tenant, MissingTenantHandler>();
   
      // OPTION 3
      // Use `SimpleTenant` as tenant model, and missing tenant handler does not have a dependency or dependency is already registered in the services
   
      app.UseMultitenancy<TMissingTenantHandler>()
   
      // ...
   }
   

2. In Program.cs, add the following in the CreateHostBuilder method.

   public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            })
            // OPTION 1: add multitenant support via TenantStartup class
            .ConfigureMultiTenancy<TenantStartup, Tenant>();
            // OPTION 2: add multitenant support via static method
            .ConfigureMultiTenancy<Tenant>(ClassName.StaticMethodName);
   

NOTE:

• Tenant must implement CodEaisy.TinySaas.Interface ITenant.
• TenantStore must implement CodEaisy.TinySaas.Interface.ITenantStore.
• TenantResolutionStrategy must implement CodEaisy.TinySaas.Interface.ITenantResolutionStrategy respectively.
• TenantStartup must implement IMultiTenantStartup
• ClassName.StaticMethodName must be of type System.Action<TTenant, Autofac.ContainerBuilder> where TTenant implements ITenant

Use Cases

TinySaas supports the most common use cases for multitenant development, and below are some examples.

Global Services

Global Services are services that do not have a core dependency on the tenant information, and they can be registered just the same way you have been used to in .NET Core, in the Startup.ConfigureServices method.

public void ConfigureServices(IServiceCollection services)
    {
        // ...
        services.AddSingleton<IGlobalSingletonService, GlobalSingletonService>();

services.AddScoped<IGlobalScopedService, GlobalScopedService>();

services.AddTransient<IGlobalTransientService, GlobalTransientService>();

        // add multitenancy support here

        services.AddControllers();
    }

Tenant Services

Tenant Services are services that have core dependencies on the tenant information. TinySaas allows you to register these services like every other .NET Core service but in a tenant aware location.

Usually, tenant services will be registered either in the ConfigureServices method of your TenantStartup class or in the delegate passed to the IHostBuilder.ConfigureMultiTenancy in the Program.cs file.

    public void ConfigureTenantServices(Tenant tenant, ContainerBuilder container)
    {
        // you can either register services using the provided container builder

        // tenant singleton
        container.RegisterType<TenantSingletonService>().SingleInstance();

        // tenant scoped
        container.RegisterType<TenantScopedService>().InstancePerRequest();

        // tenant transient
        container.RegisterType<TenantTransient>().InstancePerDependency();

        // basically, you can use all the dependency injection features provided by Autofac on the container.

        #region .NET Core DI way
        // you can also do it in the well-known .NET Core default DI way

        var services = new ServiceCollection();

        // tenant singleton
        services.AddSingleton<ITenantSingletonService, TenantSingletonService>();

        // tenant scoped
        services.AddScoped<ITenantScopedService, TenantScopedService>();

        // tenant transient
        services.AddTransient<ITenantTransientService, TenantTransientService>();

        // THIS IS VERY IMPORTANT IF YOU USE THE SERVICE COLLECTION TO REGISTER ANY SERVICES HERE.
        container.Populate(services);

        #endregion

    }

Databases

Multitenancy is not complete without databases, and TinySaas has an answer to all your needs.

Shared Database (Single Schema and Schema per Tenant)

Register your DbContext the old way and inject IHttpContextAccessor via your DbContext constructor.

// Startup.cs class
public void ConfigureService(IServiceCollection services)
{
    //....
    services.AddDbContext<AppDbContext>(...);
    //...
}

// AppDbContext.cs
public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options, IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;

        // to get the tenant information in any method
        // var tenant = _httpContextAccessor.HttpContext.GetCurrentTenant<TTenant>();
    }
}
`

Database Per Tenant

Simply move the DbContext registration to the multitenant service configuration method.

    public void ConfigureTenantServices(Tenant tenant, ContainerBuilder container)
    {
         // assume you had connectionString as a property on the tenant, you can easily do
        var services = new ServiceCollection();
        services.AddDbContext<AppDbContext>(tenant.ConnectionString);

        container.Populate(services);
    }

Other Concerns

Options can also be registered the same way as discussed for services and databases.

You can check out the source repo for TinySaas on Github, and give feedback via the issues tab.

Thank you for reading 🍾.

Top VS Code Extensions for Remote Teams:

Irrespective of what technologies your remote team uses, there are numerous VS Code plugins you will find useful, but this article will only cover those I have used extensively.

Live Share Extension Pack

Live Share Extension Pack is a suite of four awesome extensions which include the following;

Live Share

LiveShare is Microsoft's solution to enable a truly collaborative development experience. It supports real-time collaborative editing for multiple users in a single workspace (I have had up to six users on a session before). Being an early adopter of Live Share, the stability and improvements we have witnessed are quite impressive. LiveShare has given me that privilege to have memorable remote pair programming sessions with many members of my team spread across the continent with unbelievable ease.

Some amazing feature of Live Share that makes it so awesome include

• Shared Terminal
• Shared Localhost
• and even a shared debugging experience.

Live Share Chat

Communication is key, especially for distributed teams. How do you provide immediate feedback on the function your colleague just refactored. Here comes Live Share Chat

Live Share Chat provides you with a chat interface that allows you to have realtime communication will all connected users in a Live Share session.

Live Share Audio

Live Share Audio gives you the capability to make a conference call with every user in a session. It comes with exciting features like the ability to mute and unmute yourself. With Live Share Audio, Guests who join your session are automatically prompted to join the call, and right in the extension tab, you can see a list of all the people in the call, their mute status, and a button icon to mute yourself or otherwise.

Live Share WhiteBoard

Sometimes during pair programming sessions, you feel the need to sketch some things, maybe to provide more clarity to your partner.

Live Share has got you covered with this extension.

Github Pull Request

GitHub pull-request has been around for a long time but recently received massive support after Microsoft acquired Github. This extension is a great productivity hack as it allows you to review PRs right inside your favorite code editor.

GitHub PR brings the entire Github web experience into VS Code, you can do basically everything, except the new multi-line comments which is being tracked here.

We have been using Github web for years without this feature, so I don't believe it would be a blocker to adopting this extension

JIRA and Bitbucket (Official)

If your team is covered by an Atlassian subscription, and you are using any of JIRA cloud and/or BitBucket cloud, this extension has got you covered.

The JIRA part provides you with a lot of features to manage your tasks from inside VS Code, the powerful JQL language also provides you the opportunity to create a near web experience for yourself.

The BicBucket part, on the other hand, provides functionalities similar to what is obtainable on the GitHub PR extensions, and even more. One of the notable additional features is an opportunity to monitor your BitBucket pipeline right inside VS Code.

Browser Preview

Built on top of the same Headless Chrome that powers Cypress, Browser Preview gives you an almost full browser right inside VS Code, it comes handy when you need to get immediate feedback from front-end code changes. With recent updates, it brings debugging support.

Best Practices for a great VS Code Experience

One of the issues developers often face with VS Code is high memory usage, this is due to the fact that VS Code is built on Electron, this can often make VS Code unusable and sometimes your entire machine may be impacted. Here are ways I have been able to avoid sad experiences with VS Code.

Use Workspaces

Workspaces give you the opportunity to customize your VS Code experience, for a particular project, or set of projects. It gives you the opportunity to set workspace specific settings and even extensions.

If you had ever experience memory issues, and extension conflict, workspace gives you the flexibility to enable just the extensions you want.

Disable Unused Extensions

Many developers work with different technologies, and may usually have some technology particular extensions. You can improve your VS Code experience by disabling all extensions that do not relate to any project in your current workspace and/or folder. One method I employed to achieve this is by disabling all extensions by default, and only enable those extensions that are usable in the current project.

One Extension Per Feature

Have you ever run into a scenario where ESLint removed the brackets around an anonymous function, and prettier added it back immediately. This is what happens when you have multiple extensions for the same set of needs.

Work on your team's workflow, decide which set of rules you are adopting, and get the extensions necessary to enforce those rules.

VS Code was created to be lightweight, but installing too many extensions without proper separation of concern may bring you close to a Visual Studio experience.

It is almost a year I have incorporated these practices into my workflow, and I am pretty happy with this experience.

Thank you for reading, and kindly share if you feel the need.

Thanks.