DEV Community: Chris Gray

Static vs Dynamic Sites

Chris Gray — Mon, 23 Apr 2018 20:40:00 +0000

Way back when netscape was new and home internet was in it's infancy you really only had one option for a website which was hard-coding it using HTML and for year this was the standard, it made updating sites difficult, painful and often out of the reach of standard business owners. The years went on and eventually WordPress came out bringing site development to the general masses, with WordPress you could not only build and update your websites from a (at the time) easy to use interface, you could also implement a whole range of dynamic functionality like contact forms, community sites and eventually even eCommerce systems. With a wide range of functionality available it often seemed like the only limitation was your imagination for what could be done, all you'd need is a developer and a budget. With such a strong market position and range of functionality why are static sites now becoming a thing again?

What is a static site?

As outlined below a static site is usually just HTML, CSS and JS. Any content changes have to be done by manually modifying the HTML code. If you're not familiar with HTML this can be intimidating as one wrong modification can lead to your whole site looking completely wrong. So with all of this barrier to entry why would you bother versus just downloading a WordPress theme and making the tweaks you need to the style. Enter the Static Site Generator.

Static Site Generators

One of the first big Static Site Generators (SSGs) was Jekyll, Jekyll allowed you to get the best of both worlds, you could setup a number of templates for posts and pages, write the content using MarkDown in YML files, run a quick CLI tool and Jekyll would take care of the rest. This allowed you to have the fine-tuned control of a normal static site without the tedious process of creating a new HTML file everytime you wanted to create a new post. Since then the market has been flooded with tools and frameworks in just about every programming language you can think of.

Advantage of Static Sites

Performance

One of the big advantages of a static site vs a dynamic one is performance, as the site isn't having to do processor intensive queries of databases on every page load navigating around a static site is fast, really fast. With proper setup around file minification and image optimisation pages can load on a modern internet correction in the region of milliseconds. With Google putting more and more weight on site performance as a ranking tool this can have a huge benefit for both you and your business.

Flexibility

Take for a example a twitter feed, with say a WordPress site you'd likely need to install a plugin and use a shortcode to make it appear on the front-end, this introduces complexity, additional script loads and security issues all in one package. As you're editing an HTML file, implementing a twitter feed can be as simple as copying and pasting the recommended code from twitter or as complex as manually creating and styling a custom twitter feed. The only limit is your ability.

Improved reliability

As there is no back-end service or database providing content for your site there is no longer additional avialability requirements in order for your site to work. Sudden influxes of traffic will no longer cause performance issues and it will be more difficult for malicious users to bring the site down. It's not impossible and security and reliability is definitely something that should be took into account when planning and building your site but it is a lot more robust than most CMS and dynamic platforms.

No more error establishing connection errors with static sites.

Simpler hosting requirements

When you host a dynamic site you tend to need to take into account a lot of different elements, for example:

Can my host handle DB hosting?
Will it run the WordPress software?
Is the setup optimised for loading dynamic files?

When hosting a static site your requirements become much simpler:

Can I host HTML files?
Does the platform use NGINX or Apache?

Whilst there can be other requirements dependant on your deployment plan these are the two base requirements for any static site, massively simplifying your hosting and often saving a lot of money in additional software and support costs.

Downside of Static Sites

With all of the above I'm sure many of you are wondering what's the downside? Well there's a handful.

Complexity

Even with systems like Jekyll you still need to create the original layout and unlike a lot of modern WordPress themes Jekyll doesn't come with a fancy drag n' drop site designer. You need to create is using HTML, CSS and JS. This can result in you needing to bring in someone external to do the initial setup resulting in unforseen costs. Also creating new posts can be tricky, your tool for content is often just a standard text editor, whilst this can help to simplify things, dependant on the SSG you use it can also complicate things if you need to learn Markdown. There are Web UIs out there like Netlify, PrismicIO and Contentful but in my experience integrating with these has a long way to come in terms of documentation and support before I'd recommend them.

Functionality

If you need a massive eCommerce platform with auto-marketing functionality and membership areas then a static site is not going to work for you. As the site consists purely of HTML/CSS/JS files anything more complex than a contact form or a twitter feed is not going to be possible and a dynamic site or CMS platform like WordPress is going to be infinitely more suitable.

Which is better?

As you can see above both CMS/Dynamic Sites and Static Sites have their place on the web and the decision really comes down to the following:

Budget
Project requirements/complexity
Your skills and abilities
Your userbase

If you need a fast site that's seven pages and advertises an event with a contact form then by all means go the SSG route, you'll see a much greater return on ROI even if you have to hire an external developer to get started. If you need a full range membership site, with e-learning and a shop then a CMS based website is going to be a much better route to go.

Microservices 101

Chris Gray — Wed, 29 Nov 2017 17:09:00 +0000

As promised here is the first post on microservices and their advantages and downsides.

To begin with, let's define a few key terms that'll come up frequently in any discussions around microservices.

Monoliths : Not a giant column in a classic sci-fi movie but instead a monolith application. This is when all of the functionality for an application is in a single process. It's often kept in one separate repo as well however with the increasing popularity of monorepos this is becoming less frequent as an implementation method. I'll discuss some of the advantages of monoliths below.

Microservices : When the functionality of an app is broken down into multiple processes which all run separately from each other. Often implemented in different repos although as with monolith applications monorepos are changing the landscapes with this.

So with the definitions broken down let's go into some of the advantages of the different architecture types.

Monoliths

Monolith architecture actually has a lot of advantages over microservices in certain circumstances. The primary use case for a monolith would be for an MVP product, this is due to the ease in which it can be deployed, as well as how easy it can be to setup development environments. This means that your dev team can get up to speed much quicker and start being productive much faster. It's also easier to monitor the application, and as a result, it can be a lot easier to debug any issues with the app.

That's not to say there aren't disadvantages. As time progresses and your app grows you may find that your teams get much bigger in size, once this starts happening it becomes a lot more challenging to maintain the structure and communication channels effectively, see the diagram below to see how many more lines of communication are generated as your team scales.

Deployment becomes more difficult as the app increases in size and capability, and eventually, even small code changes will have the potential to become difficult to manage. Scaling will also increase in cost and complexity as you'll need to scale the whole application and not just the small piece of functionality that's gained a high demand.

Microservices

Now onto microservices. Once you start seeing some of the disadvantages outlined above for monoliths, then it is definitely time to consider changing over to a microservice architecture. Some of the advantages of microservices are detailed below.

As each piece of functionality is broken down into an individual process, it means you can have a much lower overall scope. This means that each functional unit can be designed, built, tested and deployed individually and in isolation from each other. The end result of this is that your build cycle should be able to speed up and features can be deployed more frequently.

You can also scale the features much more comfortably leading to lower running costs, instead of scaling all of your functionality at once regardless of usage you can set it to scale only the parts of the app that are facing higher usage demands. Also because of the split architecture, your app can have a much higher reliability status, if one service goes down, the app can work around it and still function without going completely down.

Microservices aren't without their downsides, because of the distributed architecture it can be much more complicated across a lot of different fronts, not just development. Debugging and monitoring will become a lot more complicated as you'll need to introduce log aggregation tools to the stack and even following where data requests have gone can lead to a trip down the rabbit holes. It can also suffer from a performance decrease due to constant API calls and communications between the services.

Reasons to move

So with the above in mind why should you move from a monolith to a microservice architecture? Well firstly because it's fun, there are a lot of challenges involved sure, but half the fun of developing is overcoming those challenges. That being said it shouldn't be a decision just from technology, there are a lot of valid business reasons to move your architecture over.

Firstly your teams will be much smaller, as you can see from the diagram above when you have a large team your number of potential communication channels increase exponentially, a small team helps massively streamline any communications. The smaller team will also be much more specialised and more efficient as they will only need to worry about the code within their functional unit as opposed to every of function within the app.

Having a smaller team can also enable organising teams around business features instead of capabilities. By organising around features instead of business capabilities, you can avoid siloed structures where the code is 'thrown over the wall' to the next department without a thought about how it will impact the team down the pipeline. It also means that teams can own the whole lifecycle from the discovery of benefit to the customer to the final release of the code into the wild without being a problem for other feature teams.

Secondly, onboarding for new team members will become much quicker as once again they'll only need to worry about how to run their single function as opposed to the entire codebase.

Finally, your releases will be much smaller and more frequent. As part of a CI/CD culture, you should be aiming to release as little code as frequently as possible. This enables you to improve the application gradually and actually deliver customer value instead of doing big bang releases of functionality that the end user doesn't actually want.

Conclusion

There are a lot of reasons to use microservices and a lot of reasons to use a monolith. As I mentioned above using a monolith for your MVP is perfectly fine, and in fact, I'd recommend it, your setup will be quicker and initially, your dev onboarding will go much more smoothly but once you start to encounter the issues outlined above definitely consider switching to microservices.

Lines of communication image is courtesy of Justin Niessner on Stack Overflow

2001: A Space Odyssey gif is used under fair usage and all rights belong to the content creator