DEV Community: Koen Barmentlo

Why we as Europeans need to ditch US tech and how

Koen Barmentlo — Sat, 08 Feb 2025 12:35:56 +0000

Recently, I've become increasingly worried about Europe's reliance on the USA due to several reasons:

Growing global tensions
The election of Donald Trump
Faster economic growth in China and the USA compared to Europe
Technological advancements in China and the USA outpacing Europe

For this post, I want to focus on the technological aspect. At my workplace, this dependency is evident. We use ASP.NET, C#, TypeScript, and Vue.js for application development, Microsoft Azure for hosting, Dell laptops with Windows, and Google for email, calendar, and online meetings. This trend is common in many Dutch companies and across Europe, including governmental organizations.

Why is this a problem?

Data privacy: The EU–US Data Privacy Framework aims to protect us from US data surveillance. However, Edward Snowden revealed the need for such protections, and Donald Trump dismantled the watchdog overseeing these practices. This raises serious concerns about data security.
Technological control: Ukraine's reliance on Starlink for communication highlights the risk. A single person in the USA can shut down this service, which actually happened. Governments and companies in Europe rely heavily on American software like Office 365, Windows, iOS, and Android, posing similar risks.
Election interference: The Romanian elections were heavily influenced by TikTok, leading to the unexpected victory of a far-right pro-Russian politician. Most social media platforms used in Europe are American, making them potential tools for political manipulation.
Economic disadvantage: NVIDIA graphic cards are more expensive in Europe than in the USA, illustrating how our dependence on American technology can put us at an economic disadvantage.

What can we do?

We can't wait for politicians to act. Change starts with us. One of the best steps is to use more European technologies. This keeps our money in Europe and supports the growth of European companies. A great starting point is European Alternatives. This site compiles and analyzes European alternatives to digital services and products, including cloud services and SaaS products. While the website is comprehensive, it doesn't cover all available alternatives. In this post, I will highlight additional tools, focusing on those useful for web developers.

Disclaimer: My experience is limited to some of the technologies mentioned below.

European alternatives

Hardware

Laptops, desktops, and servers:
- Wortmann: German manufacturer of laptops, desktops, servers, and more. The majority of their hardware is assembled in Germany under their own brand "Terra".
- XMG: German company offering laptops and desktops manufactured in Germany.
- Tuxedo Computers: German manufacturer focusing on Linux-based systems. They offer systems with Ubuntu preinstalled and their own Ubuntu-based distribution called Tuxedo OS. Windows preinstalled options are also available.
Smartphones:
- Fairphone: Dutch company focusing on ethical and sustainable smartphones. They offer two operating systems: pure Google Android without bloatware and /e/OS, which is a variant of AOSP without Google Services.
- Gigaset: German company offering sustainable smartphones running Android, manufactured in Germany.
- Nothing: British company developing smartphones and earbuds, manufactured in India.
- HMD: Finnish company offering smartphones with Google Android and feature phones with KaiOS, previously branded as Nokia.
- Murena: French company developing smartphones with /e/OS installed, assembled in China but aiming to move assembly to Europe.
Network devices:
- AVM: German company known for Fritz!Box routers, Wi-Fi range extenders, and home network extenders.
- MikroTik: Latvian company offering network routers, switches, access points, and more.
- Nokia: Finnish company specializing in infrastructure solutions for data centers, wireless networks, VoIP, contact centers, and cloud services.
- Ericsson: Swedish company specializing in networking and telecommunications, providing infrastructure, software, and services for 3G, 4G, 5G, IP systems, and optical transport solutions.

Software

Operating Systems:
- Ubuntu: Widely used Linux distribution for servers and PCs, developed by Canonical Ltd., an English company. It is based on Debian and is the foundation for many other Linux distributions.
- LineageOS: AOSP-based mobile OS maintained by a global community. It does not include Google Play Services by default but can be installed separately. It also works with MicroG, a free and open-source replacement for Google Play Services maintained by a German developer.
- Sailfish OS: Mobile OS by Finnish company Jolla, compatible with most Android apps but not guaranteeing 100% compatibility.
IDE:
- JetBrains: Czech company offering various IDEs like IntelliJ for Java and Kotlin, PyCharm for Python, Rider for .NET, PhpStorm for PHP, and more. Their IDEs are compatible with Linux, Windows, and Mac. JetBrains also offers tools for CI/CD, code quality analysis, source control, project management, and bug tracking.
Programming languages:
- Kotlin: Developed by JetBrains, suitable for various applications including API development with Ktor, multiplatform apps, data analysis, console apps, and frontend development (Kotlin can compile to JavaScript).
- Erlang: Developed by Ericsson, used in WhatsApp and RabbitMQ. It is designed to be fault-tolerant, concurrent, and hot-swappable.
Database Management Systems:
- PostgreSQL: Popular alternative to MySQL and Microsoft SQL Server, maintained by a global community of developers.
- DuckDB: Similar to SQLite, developed by the DuckDB Foundation based in the Netherlands. DuckDB Labs, run by one of the co-authors of DuckDB, is also based in the Netherlands.
- OrientDB: NoSQL DBMS supporting graph, document, and object models, part of SAP, a German company.
- ArangoDB: Graph DBMS developed by ArangoDB GmbH, a German company. It uses JSON as the default storage format and VelocyPack for serialization and storage.
AI:
- Mistral: French ChatGPT alternative supporting chat, reasoning, knowledge extraction, code generation, and image generation. They offer an API cheaper than ChatGPT, with a free version for experimenting and a pay-per-use pricing plan.
- NeuroFlash: German company offering content generation tools like text, SEO analysis, and image generation. They use models from OpenAI and provide clear pricing.
- Aleph Alpha: German AI startup developing independent AI technology for content generation, following European data protection regulations and prioritizing EU data sovereignty.

Conclusion

The list of European alternatives is not exhaustive. If you know of other interesting options, please share them in the comments!

Best coding practices: secure dependency management

Koen Barmentlo — Wed, 03 Apr 2024 13:09:07 +0000

Modern application are often written with help of (too) many third party libraries. Take a look inside of a random node_modules folder for example. These packages contain security vulnerabilities which could lead to serious data breaches, account takeover, money theft and more. Sometimes malicious code is put in third party library by a malicious actor (supply chain attack). Other times they are just mistakes made by developers. As long as you use third party libraries you're always at risk of using one (or more) vulnerable ones. This post is about things you can do to minimize the risk of becoming victim to these kind of vulnerabilities.

Don't use dependencies you don't really need
If it doesn't take much time to write it yourself, do so. Especially if you only need a small part of a big library. You never know if someone has added malicious code to it or if it is using a vulnerable dependency unless you validate all that code. This makes dependency management much easier.

Use dependencies for big and hard things
Don't write your own code to handle hard things like handling authentication tokens. You will probably make mistakes which leave your application vulnerable. Pick a library for these things and take next paragraph into account.

Every time you start using a dependency, take a look at who created it

If the package is open source and is being maintained by a very small group off people, there is a bigger chance that one of them adds malicious code without anyone noticing.
Pick packages which are maintained by bigger companies like Microsoft, Oracle or Google. They hire good and professional people who know what they are doing. Don't install packages from RandomDude from RandomCountry and if you do, do some background research on that person so you know if it's a skilled and reliable developer.
Check if there is no known vulnerability in the version of the package you want to install. You should be able to find this in your package manager like in this example.
Check if the dependency is actively maintained. If it is marked as deprecated it is not supported anymore and you should not use it. You can also look at the commits on Github or the last time a new version was released.

Scan your projects for vulnerabilities regularly
More development platforms add features to check if the dependencies of your application contain a vulnerable packages. In modern ASP.NET you can use dotnet list package --vulnerable and in NPM you can use npm audit. It's even better to automatically scan your dependencies regularly. You can use tools like snyk or mend.io (formerly Whitesource) to help you with that. Those tools are expensive but have some advanced features.

Validate your package sources
Make sure all you dependencies are downloaded from reliable and legitimate sources like NuGet.org from Microsoft or your own (well secured) private feeds. If you are using multiple feeds a package could be available on both sources so one of them might contain a malicious or version so you could accidentally install the wrong one.

Use lock files
Lock files contain the hash of a package's content so if it changes, you will be able to see it.

Scan Docker images
If you are using Docker images you should use Docker scout to scan for vulnerable images regularly.

What to do if you find a vulnerable package in your project

If there is a fix for the vulnerability you should update the package and release it as soon as possible.
If not you should assess if the vulnerability is making your application vulnerable and if so try to find a workaround to fix it. Sometimes workarounds are provided by package authors.
If the vulnerability has a low severity rating you might chose to do nothing or wait for a fix.

Do you know other best practices for managing software dependencies? I'd love to read them in the comments!

Best coding practices: where to put your authorization logic

Koen Barmentlo — Wed, 03 Apr 2024 11:02:11 +0000

Web application often have several layers which have different responsibilities. You'll almost always find the following three layers, but there could be more.

Presentation layer: responsible for user interactions
Business logic layer: handles functional requirements
Infrastructure/persistence layer: responsible for handling data and databases

So where do we put our authorization logic?

Let's begin with the infrastructure/persistence layer. It is possible to add authorization here, because you could easily define the data a user should have access to. Still I don't think this is a good option for most applications for several reasons:

Most of the times users should only have access to the data they need. So if a functional requirement changes you must add changes to a lot of code within the infrastructure/persistence layer.
It is very easy to change something like adding a join in a SQL query and forgetting to change authorization accordingly.

What about the business logic layer? I think this is a better option, because in here you can define exactly what business actions a user should be allowed to have access to. Especially when a piece of logic should be executed from multiple applications. For example a desktop app and an Android app. But it has a big disadvantage:

Some of your functions are called from several places. For example: function A calls B, C calls B and D calls A. So adding authorization could make things pretty hard and it's easy to forget to add it somewhere.

How about the presentation layer? In my opinion this is the best place because of the following reasons:

Many frameworks handle authorization here like ASP.NET , FastApi and Laravel.
You can exactly see which data will be return by an endpoint or on a page so you can easily decide which users should have access.
It's almost impossible to forget an authorization because you can easily browse your routes and see if every single on of them has authorization.
Authorization is handled at the beginning of a request. No business logic (or very little) is executed yet so that lessens the chances of introducing a business logic vulnerability.

It would look something like this:

[Authorize]//makes sure a user is logged in
[Route("api/[controller]")]
[ApiController]
public class ValuesController(MyAuthorizationValidator myAuthorizationValidator) : ControllerBase
{
    private readonly MyAuthorizationValidator validator = myAuthorizationValidator;

    // GET: api/values
    [HttpGet]
    public ActionResult<IEnumerable<string>> Get()
    {
        //other authorization rules which could not be handled by [Authorize]
        if (!validator.IsAllowedAccordingToMyCustomAuthRule(HttpContext.User))
        {
            return Unauthorized();
        }
        //Run business logic
        return new string[] { "value1", "value2" };
    }
}

Do you prefer to put authorization logic in a different place? Or do you have other reasons to put it in the presentation layer? Please let me know in the comments!

Modular Dependency Injection in .NET

Koen Barmentlo — Mon, 25 Mar 2024 21:09:48 +0000

When I was building application with .NET Framework I always used libraries like Autofac and SimpleInjector for dependency injection. I really liked to create modules (Packages in SimpleInjector) to achieve higher cohesion and lower coupling in my class libraries. I made a module for every class library in which all dependencies inside of that class library were registered. Why should my web application (for example) know if MyBeautifulService in MyBeautifulClassLibrary should be transient or singleton?

.NET Core 1.0 has built-in dependency injection support but it still lacks modules in later .NET versions (or that's what I thought). While it is possible to use Autofac and SimpleInjector in .NET Core I ran into issues and difficulties pretty quickly when I was building some Azure Functions:

I build my own Module feature with the Microsoft dependency injection which was pretty easy to do. But the way I was thinking was much to difficult. Why would I not do it in the same way Microsoft is doing it? So now I do it like this:

public static class MyBeautifulClassLibraryExtensions
{
    public static IServiceCollection UseMyBeautifulClassLibrary(this IServiceCollection services)
    {
        services.AddTransient<MyBeautifulService>();
        return services;
    }
}

If you prefer you can also create an extension method like this per feature instead of per class library.

Happy coding!

Web application too slow? Here are some easy ways to speed things up.

Koen Barmentlo — Wed, 17 May 2023 11:04:25 +0000

Is your web application not fast enough? Or does it slow down when many requests are coming in? Here are some easy ways to fix it.

Browser/HTTP caching

Web browsers are capable of temporary storing (caching) data that has been retrieved from a server before. You can use browser caching for images, CSS, JavaScript and other files, but also for dynamic responses from API endpoints. Browser caching can be implemented by HTTP headers like ETag, Cache-Control, Last modified and more. Web Application frameworks have features to make implementing these headers easier.

With a technique called cache busting you can make sure your users see the latest version when you deploy a new version of your web application.

Be careful with sensitive data. When a user logs out and another user logs in the second user could access the data of the first user if not configured correctly.

CDN (Content Delivery Network)

A CDN can increase the performance and scalability of your server a lot. A CDN fetches static assets like HTML, CSS and images from your website and stores them on CDN servers. In your application you point to the CDN URL instead of your own URL. Web browsers will make requests to the CDN so this reduces the load on your server a lot. There are many CDN providers to choose from like Microsoft Azure and Cloudflare.

Be careful with sensitive data. You don't want that on an external server.

Memory object caching

Caching objects in memory on the webserver is also an option. For example, let's say a user calls an endpoint which does the following:

Checks if data is available in the cache. If not:
- Gets some data from the database
- Makes some heavy calculations
- Uses memory object caching to store the results for five minutes
Returns data to user Because the data is being cached the data only have to be fetched from the database once in 5 minutes. Same goes for the heavy calculations. Only one user per 5 minutes have to wait for all this and it reduces the resources needed on the web server and database server. This off course comes at the cost of more RAM usage. Here is a simple example on how to implement this in .NET Core:

[Route("api/[controller]")]  
[ApiController]  
public class ValuesController : ControllerBase  
{  
    private const string MY_CACHE_KEY = "my-key";  
    private readonly IMemoryCache _memoryCache;  
    public ValuesController(IMemoryCache memoryCache)  
    {  
        _memoryCache = memoryCache;  
    }  

    // GET: api/<ValuesController>  
    [HttpGet]  
    public IEnumerable<string> Get()  
    {  
        return _memoryCache.GetOrCreate(MY_CACHE_KEY, cacheEntry =>  
        {  
            cacheEntry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);  
            return GetValuesFromDatabaseAndPerformCalculations();  
        });  
    }  
}

If you want to cache personal data of users, include a user identifier in the key so users cannot access each others data.

Horizontal scaling

Horizontal scaling is about adding extra servers on which a application runs. A load balancer distributes the requests evenly among the servers.

Cloud platforms like Microsoft Azure and AWS or technologies like Docker or Kubernetes provide features to make horizontal scaling easier. However, there are some downsides to this solution.

If the application keeps a state like data/variables in memory or data on the hard drive for example, you need to implement sticky sessions so the user will be directed to the right server.
You might want to dynamically add servers at a specific time or when the load on the application gets too high. Sticky sessions aren't an option anymore. The load balancer can't direct a user to the newly added webserver, because of the sticky session. If a server gets removed the state stored on that server is also removed. Dynamically adding and removing server requires an application to be completely stateless.
An extra server is more expensive.

Distributed caching

Memory object caching makes an application stateful because data is being stored in memory. If you have two servers which have different versions off data cached, users will see inconsistent responses. Distributed caching is the same as Memory object caching except that the data is stored on an external server. This comes at a cost of extra complexity and money. With technologies like Redis, Memcached and others it's possible to horizontally scale the caching nodes if one node isn't enough. Distributed caching can also be a great option if memory cache is taking too much RAM from your webserver.

Do you really need "microservices"?

Koen Barmentlo — Sun, 14 May 2023 12:29:48 +0000

Web applications are often divided into multiple deployment units. Often their called microservices and most of the time they are not really microservices. An architecture that is divided in multiple deployment units is called a distributed architecture. A deployment unit is a self-contained package of software components which can be individually deployed. An example is a single web application with its database. In web applications, deployment units are connected through protocols such as REST, SOAP, Events or others. An architecture which is not is called a monolithic architecture.

Advantages of distributed architectures over monolithic architectures

Deploy applications over several machines and you'll have much more computing power available.
When designed well, applications won't go down completely if a part of the application goes down.
Multiple teams can work more easily individually on a part of the application.

Sounds great right? Well, there are a lot of challenges and disadvantages to face if we choose for a distributed architecture. In the next section I will describe them.

The fallacies of distributed computing

The fallacies of distributed computing are a set of eight false assumptions programmers and architects often make. They're made by L Peter Deutsch and others at Sun Microsystems in 1994. The next section will describe them and provide options to deal with the problems these fallacies might cause.

Fallacy 1: The network is reliable.
If system 2 works perfectly well, but is not accessible for service 1 due to network issues, service 2 is still unavailable. This is why timeouts, service breakers and retry policies exist. A great tool for .NET to handle common network issues is Polly, but even when using a tool like this, the network is still not completely reliable.

Fallacy 2: Latency is zero
If component 1 calls component 2 within a monolith the latency is almost zero. If a network call has to be made, the time it takes for the call to be completed will be much longer. Especially if many network calls have to be made. If the latency of a particular call is 100ms and we'll chain ten calls, latency will add one second to complete the business process.

Reduce the number of network calls. Instead of sending multiple pieces of data individually, send them in the same request.
Latency could be reduced by moving the data closer to the client. If the client is in West Europe, make sure your data is in West Europe as well.
Temporary caching data could reduce the number of network calls, reducing the latency to zero if data has already been fetched. Storing data locally at the client (with an pub/sub model for example) could also be an option to reduce the latency to zero.

Fallacy 3: Bandwidth is infinite
Let's say component 1 fetches 500kb data from service 2. That doesn't sound like much, but if that happens 2.000 times, 1Gb of bandwidth will be used. This is could cause increased latency and bottlenecks. Therefor, monitoring bandwidth is probably a good idea in a distributed architecture. Ways to reduce the amount of bandwidth are:

Caching
Storing data locally
Compression
GraphQL
Field selectors
You could also use lightweight data formats like JSON or a binary serialization format.

Fallacy 4: The network is secure

The attack surface of distributed applications is much bigger than the attack surface of distributed applications. Every single component should be secured because there are many ways you're application can be attacked like XSS, vulnerabilities in operation systems, libraries and DDOS just to name a few.

Fallacy 5: The topology never changes

This fallacy is about every network component like routers, servers, firewalls and proxy servers. The topology changes all the time. Updated network components could make services unavailable, if a component breaks it will be replaced, if a server can't handle the request anymore it could be replaced or a load balancer and an extra server could be added. With modern technology like Kubernetes, Docker and Azure app services for example, virtual machines or containers could even dynamically be added or removed.

Use host names instead of hard coded IP addresses.
If that's not enough, use discovery services.
Service bus frameworks could also help, because every components communicates with the service bus.
Automate as much as possible so you can replace a server as quickly as possible .
Monitor all services.

Fallacy 6: There is only one admin

Distributed architectures are complex, especially when they get big. It can't be maintained by a single administrator so it requires a lot of communication between teams to make everything work correctly. This makes decoupling, release management and monitoring extra important.

Fallacy 7: Transport cost is zero

This fallacy is about money. With a distributed architecture you will need extra servers, extra proxies and firewalls etc. which makes a distributed architecture more expensive. If you want to cache data, like discussed in fallacy 2 and 3, we might need extra server memory or a Redis cluster. If we use compression like discussed in fallacy 3 we would need more computing power to compress data. Extra resources are also needed for serializing and deserializing of data. These things might seem cheap, but at large scale it could become very expensive.

Fallacy 8: The network is homogeneous

Networks consist of different components of different vendors which have to be compatible with each other. In a distributed architecture a lot of different combinations of components can be used and not all of them are fully tested. We also don't have control of which browsers and devices connect to you're service. This fallacy isn't all about hardware. It's also about software.

Try to use open and popular standards like JSON or XML.
Using PaaS or IaaS providers will take some hardware challenges away.

Other challenges

Monitoring

Finding bugs in a distributed architecture is hard. In a monolithic application there is one log instead of several. Combining all these logs is necessary to trace what happened when an error occurred. There are tools for this, but it's still much more difficult than a single log.

Contract versioning

When multiple components talk to each other they need to understand each other. A data contract is used for this purpose. A data contract describe the messages being sent from one component to another. It consists of which kind of standard is being used (XML or JSON for example), properties, datatype and the structure of data. Contracts can't be changed because it might cause another component to break. Therefor contracts need versioning to be able to migrate to a new version of a contract. Changes in contracts must also be communicated to other development teams and there should be an overview of which deployment unit uses which contract so you know when you can remove an old contract.

Deployment

Many components have to be deployed in a distributed architecture.

Make sure components are loosely coupled so each can be deployed individually .
Automate deployments to reduce the amount of work deploying all components .

Distributed transactions

Transactions are easy in monolithic applications. Begin transactions -> do stuff -> commit or rollback transaction. But what if the stuff you want to do requires actions in multiple components? Technologies exist to handle these situations, but that's still much more complex than transaction that are not distributed. Distributed architectures often rely on eventual consistency.

Local development

Local development with a distributed architecture can be done in two different ways. The first is to setup all the components (or only the subset of components required by a developer) of the application. The larger the application gets, the harder and more time consuming this process gets. The other way is to setup an extra environment for development purposes. This environment must be maintained and will come with the cost of extra hardware. Infrastructure as code or scripts make life easier setting up new environments. Debugging is also much harder in a distributed environment.

What kind of application could be suitable for a distributed architecture?

Applications with a huge code base. I used to work at a company where I had some colleagues who worked on a huge monolithic application which took hours to compile. In this scenario a distributed architecture could be a good idea.
An application built in a big company with a lot of developers.
Applications which needs to be very scalable.
Applications where availability is very important.

In all other scenario's a monolithic architecture is probably the best approach.

I hope that by now you can choose if your next application will be monolithic or distributed, but that doesn't mean you're done yet. There are different types of distributed and monolithic architectures each with their own advantages and disadvantages. It's important to know about them and make a good decision.

Details of these types are out of the scope of this post, so I will only mention some of them.

Monolithic architecture types

Layered architecture
Pipeline architecture
Microkernel architecture

Distributed architecture types

Service oriented architecture (SOA)
Microservices
Serverless

I hope you enjoyed reading this and I love to hear any feedback!