DEV Community: Erik Madsen

Microplatforms

Erik Madsen — Mon, 25 Nov 2024 13:42:27 +0000

Over the last 10-15 years we've seen the industry adopting microservices in order to achieve a number of benefits often related to scaling technology and organisations.

The pattern has also been emulated for the frontend in what is known as microfrontends.

To enable this evolution, many organisations have adopted DevOps practices to provide greater collaboration and leaner processes between developers and operations, because, quite simply, it's hard to maintain a larger number of deployable components if deployment cycles are slow and collaboration is inefficient.

Part of this work has been providing developers with good self service tools and APIs so that they can carry out their deployment tasks with, ideally, ever increasing independence and efficiency.

Many organisations have found value in providing standardised configuration patterns and middleware when general infrastructure-as-code tools turn out to be too low level of abstraction for their needs.

Over time, in-house practices, tools and APIs have developed into what we refer to as internal developer platforms, and organisations opt to have dedicated platform teams to maintain and expand the platform in the hopes of improving automation and enabling better compliance and security.

Despite the good intentions, more and more we're seeing that the platform and its corresponding organisation comes with a built-in temptation to centralise and pursue (fictitious) economies of scale, and I think it's fair to say that a lot of teams are realising that they have invited the ghost of the monolith back in to the house in a different shape.

It's therefore prudent to start thinking about the next step in the evolution of the platform with a strong emphasis on its original DevOps aspirations.

We might call this step Microplatforms.

I believe they will have some of the following traits:

Deeply specialised to the needs of individual teams
Organisationally decoupled
Might reuse or further abstract components and policies from upstream platforms on an opt-in basis.
NOT separated from the development teams by a ticketing system
Well-suited for ownership by cross-functional teams
Small
Quickly iterated
Easily replaceable
Maintained and expanded with the primary emphasis on removing friction from developers in delivering value

We would do well to remember the hard earned lesson, that when it comes to software all things are better when they're kept small. Micro, in fact.

Process-based parallel execution of plain Minitest tests

Erik Madsen — Fri, 01 Nov 2024 12:49:57 +0000

I started work on a new gem today.

When I created my previous gem, churn_vs_complexity, I decided to use the new and exciting test library Tldr because of its philosophy of fast test suites.

While the experience of using that tool was nice overall, there were times where I got a bit of friction from its slightly unpolished current state (in fairness, no version 1.0.0 has been released yet) and the fact that it's not extensively used by the community.

In my new gem I wanted to see if I could use Minitest but keep the same, albeit less draconian, focus on speed of execution.

One thing I wanted to keep from Tldr was process based parallel execution from the onset of building my test suite.

My understanding is that Minitest has some built-in support for concurrently running tests, but it's thread based, so the Global Interpreter Lock (in runtimes that have one) will mean that the Ruby code will not be executing in parallel. It could still give you a performance boost if your tests perform I/O.

But I want the real deal. I need process-based concurrency so that my Ruby code can also execute in parallel.

I had a chat with my AI about how I could go about this, and it gave me a lot completely wrong answers with the utmost confidence. So after a while I decided I had to go back to attempting to be competent myself.

You might remember that Rails introduced built-in concurrent testing in version 7 for the Rails flavour of Minitest where test cases inherit from ActiveSupport::TestCase.

That particular class has too many batteries included for my use case, but I wanted to see if I could reuse ActiveSupport's way of instrumenting Minitest for parallelism.

After a bit of tinkering and reading the source code of ActiveSupport::TestCase, I found the solution I was looking for. It obviously requires ActiveSupport as a test dependency, but configuration-wise it's nice and lightweight.

I published the approach in the following GitHub Gist, and I'll likely reuse this pattern in other gems. Maybe it'll be useful for you as well.

Here's some example output of running rake test where we can see the parallelism in effect:

Running 2 tests in parallel using 10 processes
Run options: --seed 46661

# Running:

..

Finished in 0.211560s, 9.4536 runs/s, 9.4536 assertions/s.

Elapsed time in Ruby, leap second safe

Erik Madsen — Sat, 28 Dec 2019 12:21:14 +0000

I highly recommend this article if you're interested in robust and reliable ways to build business logic that includes the notion of elapsed time.

"Elapsed time with Ruby, the right way" by Luca Guidi
https://blog.dnsimple.com/2018/03/elapsed-time-with-ruby-the-right-way/

Article - Destructuring With Ruby

Erik Madsen — Sun, 28 Jul 2019 10:14:18 +0000

I was looking around to see if there was a nice way to use the splat operator or some other technique in Ruby to extract some values from my custom object. Found this nice article on the subject.

https://jsarbada.wordpress.com/2019/02/05/destructuring-with-ruby/