https://rogerjohansson.blog/2017/05/19/do-not-do-in-code-what-can-be-done-in-infrastructure/ Skip to content Roger Johansson Blog Roger Johansson Blog .NET, Go, Distributed Programming. Close collapsed * Presentations and Workshops * Contact * Twitter * Github * Facebook * Meetup * Linkedin Menu expanded Do not do in code what can be done in infrastructure May 19 2017May 20, 2017 Or subtitle: Maybe distributed programming is no longer a programming problem? (For the obvious impaired: This is meant to be more thought provoking than an actual truth) Over the last decade we have seen the emergence of cloud computing, multi core, and micro service architectures. Due to this there have been a trend for new languages and frameworks for distributed programming. Frameworks such as Akka, Microsoft Orleans and languages like Erlang, Elixir or Pony have increased in popularity. The issue for such tools is that they are all programming concerns, you have to write code to leverage their power. One of the major benefits of languages like Erlang or the actor model in general is it's somewhat unique fault tolerance and supervision support. You can tell an actor system to ensure that a specific process should always be running, and if it fails, it will be recreated. Given the introduction of containers, cluster orchestrators and the mindset of "cattle not pets", we can now employ the same or similar ideas on an infrastructural level. We can make sure that we always have X instances of a given service or process running in our infrastructure. Docker Swarm, Kubernetes, Nomad and others make this possible. Other infrastructure like Traefik, LinkerD, Envoy makes it possible to do call retries, circuit breakers, rate limiting for service calls, Tools like Consul and Etcd gives you service discovery on a DNS level. The infrastructural approach is of-course a more blunt, less fine-grained alternative than the actor model or similar tools which gives you complete control. But it is still a step in an interesting direction; Do not do in code what can be done in infrastructure. I am not saying that you should stop using such tools as they are extremely powerful. What I am rather asking is; are you aware that this is the case? Some of the hype and arguments for these languages or frameworks can now be leveraged cross cutting between your systems in the infrastructure. Pick the right tool for the job and Don't drink the Kool-Aid. Share this: * Twitter * Facebook * Reddit * LinkedIn * More * * Print * Email * * Related May 19 2017May 20, 2017 [be674] Published by Roger Johansson View all posts by Roger Johansson 2 Comments 1. Pingback: Do not do in code what can be done in infrastructure | Ace Infoway 2. Pingback: 1 - Do not do in code what can be done in infrastructure Leave a Comment Cancel reply Enter your comment here... [ ] Fill in your details below or click an icon to log in: * * * * Gravatar Email (required) (Address never made public) [ ] Name (required) [ ] Website [ ] WordPress.com Logo You are commenting using your WordPress.com account. ( Log Out / Change ) Google photo You are commenting using your Google account. ( Log Out / Change ) Twitter picture You are commenting using your Twitter account. ( Log Out / Change ) Facebook photo You are commenting using your Facebook account. ( Log Out / Change ) Cancel Connecting to %s [ ] Notify me of new comments via email. [ ] Notify me of new posts via email. [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] Search for: [ ] [Search] Blog Stats * 1,518,628 Views Top Posts * Do not do in code what can be done in infrastructure * Random things learned building Akka.NET - Part 1 * Genetic Programming: Evolution of Mona Lisa * Why mapping DTOs to Entities using AutoMapper and EntityFramework is horrible * Presentations and Workshops Roger Johansson Blog, Blog at WordPress.com. Send to Email Address [ ] Your Name [ ] Your Email Address [ ] [ ] loading [Send Email] Cancel Post was not sent - check your email addresses! Email check failed, please try again Sorry, your blog cannot share posts by email. [b]