I'm usually making quite a bit of noise trying to promote the "original" idea of DevOps. That is, the unifying practice of tackling development and operations together as part of delivering a software product.
Many (particularly in the world of recruitment) use DevOps as a synonym for Ops when referring to a role. This is not the intention of the concept, though that's a point I've talked about in other articles.
This article is about the first step towards DevOps (or at least what I consider a first step to be). Of course, DevOps doesn't mean one person needs to have complete master over both areas but there has to be some crossover so that people know what the person next to them is talking about.
There's a simple way to make a step towards that understanding: know your tools. Specifically, know what it takes to run your application.
I know many frontend developers whose knowledge about running an application is limited to "yarn start" and know little about production builds, static builds or what it takes to enable React routing on a practical level. How do you make a random URL still hit that entrypoint of your SPA?
In the development world, people talk about learning a programming language. But that's rarely (if ever) what it is all about. When people talk about learning a language, they actually mean (whether they know it or not) three things.
Language
A programming language is just that. A language. You speak to a computer in a language which gets translated into something that the computer can understand and, most importantly, obey.
There's syntax as well as a translator (depending on language type it can be a compiler or an interpreter).
There's little to say about that. Whether it's the syntax of the English language or the syntax of Java, it boils down to learning the meaning of things and how they work to enable your communication. We have punctuation, expressions and whatnot. Learning syntax is tedious but once you've done it for a language, next time around it helps to identify similarities (just about any language has ways of working with filesystems, for example or doing loops).
Platform
Here is where things get interesting. The platform is the thing that executes your program once the translator has done its thing of helping the computer understand what you want.
For Java (and other languages of the family, such as Scala or Kotlin), there's the JVM. In the case of Javascript, it could be V8 or SpiderMonkey. For PHP it could be FPM or other platforms that rely on CLI (such as RoadRunner). For languages that compile to native binaries (like Go), the platform is the OS itself - with some benefits (performance) and drawbacks (you need to compile separately for every OS and CPU architecture that you want your application to run on).
Platforms can be wrapped into virtualisation methods, such as containers. This also has benefits (you can package an environment with all its tweaks and run it anywhere the virtualisation is supported) but also drawbacks (there's another layer to know about, even if it's a thin one).
This is important to understand because platforms may come with requirements. This could be related to third party applications (PHP FPM's needs a proxy to be usable via HTTP for example - that needs configuration and ways of monitoring it in a production environment) or various dependencies (like OS packages that need to be available).
There are some issues arising here. For example, you may be developing with the same language but on a different platform in your development environment than your production environment. I often found PHP developers using a simple basic Apache setup locally when their application was delivered using FPM + Nginx. Differences in platform or its dependencies can be insidious as they may not be obvious. I'm configuring just a bit more RAM in my FPM as opposed to production. I'm using a single threaded module locally but multithreaded in production.
Ecosystem
The ecosystem around a language refers to the documentation (first-party documentation but also community) and libraries/frameworks made available to make your life easier.
A common way to look at the ecosystem is through the number of libraries/frameworks available. Usually a mature language that has been around a while and it's been battle-tested has a sizeable community and lots of libraries.
But there's another way to look at it. A large ecosystem is hard to maintain in general and within that large number of frameworks and libraries it's guaranteed that many are no longer maintained.
This in turn poses a challenge. In a large ecosystem that's constantly changing, is it wise to go for a given library? If you aim to have a robust software product to maintain for years to come, you also need robust libraries that are maintained so that they will be kept up to date with platform changes. This is also needed because old versions of a platform are eventually left without much needed security updates (once end-of-life comes) and today more than ever it's important to never be tied to a dead version of a platform or else you'll end up in the wrong kind of HackerNews.
All this means is that as a developer, the syntax of a language barely counts as scratching the surface. If you're in the development business for the long run, you must learn the platform and the ecosystem as well.
Top comments (0)