Are you responsible for managing a website? If you are you probably know that
what seems like every few years it is time to "refresh" the site and often that
means reviewing everything that is there and trying to update or re-implement
things in the site.
Quite often the project becomes overwhelming as you realize all of the features
that have been added to the site over the years. A lot of things happen when a
site is in "maintenance mode" and what seems like a small project can quickly
become large when this is factored in.
A common question we were asked in the 2010s was "can't we just go part-way
with this, upgrade one feature, and move onto the next" but in the early 2010s
most CMS software would not allow this approach or would make it quite
difficult. Each few years a new major version would come out and force a bunch
of re-working to occur.
Enter the Microservices Era
In the late 2010s a new trend started: to split up the functions of a website
into "microservices". This essentially means dividing up the functionality of a
site into logical parts and dealing with them separately - either embedded in
the page or hosted on a different domain.
The main idea is to isolate the development and testing of that "component" so
that it is easier and less risky to make changes.
So what is an "app" exactly in this context?
For a typical brochure site you may have something like this in terms of "apps"
running the site:
- Contact form
- Shopping cart
...but the rest of the site is largely static.
A microservices architecture would suggest a collection of apps that are
presented together as one website. Our collection of apps for the above site
would be the following:
- a CMS application - used for managing content and visual assets
- a static front-end application - used to generate static pages for content
- the contact form app
- the shopping cart app
The benefit of rendering a static site is that if any of these other services
goes down the users may not even notice. CMS applications often require
frequent security updates so rendering static files from the CMS acts as an
extra layer of security by not exposing that part of the application to the
public at all.
Another benefit of this strategy is that we could swap out different components
of the site for different solutions, including commercial options. So unlike
getting WooCommerce because you are using Wordpress, you could alternatively
use a service like Snipcart or Shopify or many others.
Faster Dev With Some Additional Complexity
As you embrace microservices you will start to enjoy that each of your little
"apps" is now self-contained and much smaller than the original beast of a
project you were dealing with before. It is all rainbows from here on out,
right? Well, not really. As is usual with programming tasks you are really just
choosing to have a different problem to solve.
In this case the new problem to solve is how to make sure everything is always
running together and running well.
Testing that the website is "up" is a great starting point. That might only
test your static files though, so it is also important to note if our shopping
cart widget loaded. What happens if it fails to load? Do the users see the
contact form? Is everything available and functional?
All of the individual apps need to have their own tests to ensure they do what
they are supposed to do. An additional layer of integration tests is necessary
to ensure that the different apps are working together in the way you want
Keeping Good Records
Once you have all of your tests in place things are going to start feeling
really good and you're going to be able to iterate quickly on new challenges
and deploy faster due to less scope of testing when you have made a change.
That's great! With automated tests this gets even better.
What happens when you try to onboard a new team member though?
If you were doing CMS-based development there would be a "typical way" things
are done and that would enable developers to get to work quickly without having
to put much thought into the architecture. If you are developing multiple apps
from scratch things can go awry really fast when a new developer isn't aware
that part of your app already does something that they are in the process of
The way around this issue, of course, is to write documentation. Specifically
to write good requirements even if it means documenting the software after it
is written. It should be factual and to-the-point so other developers can rely
on it to answer questions without involving the project architect for each
Some projects may opt to keep the documentation as part of the code repository,
while others may want to keep it internal to their team on some form of wiki.
Either way, getting a high-level overview of your project "in writing" will
help you work with other developers so they can understand the intention of how
your project is supposed to work.
Another tip on the documentation front: keep a changelog. For some of our
smaller projects we manage the changelog as more of a "monthly report" that
captures requests and bugs. This will help other developers see where project
is being made so they can focus their energy appropriately.
Potential for Cost Reductions
One final word about microservices... as you embrace microservices your hosting
costs will likely start trending downward, perhaps all the way to zero.
Going back to our list of services our site offers:
- the CMS (no longer serving data to the public - therefore could use "free" tier of some hosts)
- the front-end static rendering process - could be generated by a continuous deployment pipeline, some of these services offer a free tier as well, and deploy the files to a free static host like GitHub pages or others
- the contact form could use a hosted service (formspree.io, etc)
- the shopping cart could use a hosted service (snipcart, shopify, etc)
For those last two you might choose to pay for a service. Or perhaps you will
set it up in a smaller more focused hosting account. Or... perhaps you design
that part of your application to run once and be done, so you could make a
"serverless" script that processes what you need which can cost a lot less than
managing to run a server 24x7 and having to make sure it is always running. The
best part of this is that you get to make the choice of what strategy will be
best and if it isn't working for you it will be possible to swap out that one
part for another service without disrupting the things that are already working
and which you are happy with.