The growing influence of containers, microservices, and cloud-native computing is changing the way developers think about building and deploying applications. As a result, the need for a more flexible and dynamic approach to DevOps is increasing. This is where the role of languages comes into play.

In the past, DevOps teams were largely reliant on a limited set of languages, such as Bash and Python. However, as the complexity of applications has increased, so has the need for a wider range of languages. Today, DevOps teams are using a variety of languages, including Go, Rust, and Node.js, to build and manage their applications.

This change is being driven by several factors, including the need for higher performance, the need for greater flexibility, and the need for a more collaborative environment. Go, for example, is a high-performance language that is well-suited for building microservices. Rust is a memory-safe language that is becoming increasingly popular for writing systems software. And Node.js is a JavaScript runtime that is widely used for building web applications.

The use of a wider range of languages is also leading to a more collaborative environment. In the past, DevOps teams were often siloed, with developers working in one language and operations teams working in another. However, as the use of multiple languages has become more common, teams are finding that they need to work together more closely. This is leading to a more collaborative and productive environment.

The changing landscape of languages in DevOps is having a number of benefits. First, it is leading to the development of more innovative and scalable applications. Second, it is making it easier for teams to collaborate and work together. And third, it is leading to a more efficient and productive development process.

As the use of containers, microservices, and cloud-native computing continues to grow, it is likely that the role of languages in DevOps will continue to evolve. In the future, we can expect to see even more languages being used in a wider range of ways. This will continue to drive innovation and improve the way that applications are built and deployed.

One of the places development has made significant changes is in the land of APIs. These days, a program almost isn’t considered a proper application unless it offers APIs to do most of what can be done via UI (and even command line). This is a big deal for several reasons; first and foremost, the ability to subdivide the work and then test each subdivision. A proper API does one thing and does it well. Testing can validate that this statement is true for any given API. It also allows for distribution of processing. It is far easier to use a load balancer to scale APIs than it is to scale a monolithic application. And finally, it helps with portability, because with API-first, developer users don’t care what platform it’s running on, just that it can be reached via URL and responds as expected.

Everything is a trade-off, and there are several places that API-first has issues. Integration testing is objectively harder. Loosely coupled applications, in general, are harder to test, and requiring multiple portions of an application be available to run testing becomes onerous, particularly as the layers of APIs start to build up. Second, security is another issue – particularly if you’re offering a public-facing API, but also for internal usage. Once an attacker has access to the network, internal-only APIs are no different to them than external. Smart IT departments design internal APIs with the same controls that external requires. Third is DevOps in general. API-first grew up in the agile/DevOps world, but because there are cascading dependencies, is actually harder to manage DevOps for than most monolithic applications. Finally, documentation – the bane of API-first’s existence. The number of poorly documented APIs vastly outnumbers the astoundingly well-documented ones. Even well-documented APIs, like Google Places, require some thought and testing to use well. Poorly documented ones – my favorite is, “It’s mysite.com/users – everyone knows what’s in there!” – are next to useless without a learning curve.

With all of that said, what about languages? That greatly depends on what you’re doing. Users don’t care what language it is implemented in – as noted above, they care that the API can be reached via URI, and that it behaves as expected. So you do have options. Indeed, at this point in the evolution of APIs, the language options are so open that you’ll probably be choosing an API definition language instead of a programming language, and just instruct your definition tool to spit out the language of choice.

Wait, what?

For those who haven’t followed API development closely over the last few years, it goes something like this. APIs became standardized, then APIs became a big deal, then smart people started to think in terms of code generation á la ancient 4GLs. What if you could use a specification language to describe what you want to do, then pick your language and tell the tool to generate the API? What if you could do this for the entire API hierarchy? That’s where we are. I’m most familiar with OpenAPI and RAML, but there are a large number of specifications out there, and a larger number of tools to develop in them. Before my API friends freak out, of course this is an over-simplification of what happened. I only have 1000 words, max, and my editor would like less. Relax a bit.

And then you generate.

I’ll rely on my own experience here, but there are literally dozens of tools available to get you from idea to API interface (doing the work behind the interface is where you come in). With Swagger CodeGen, the tool I’m most familiar with, you specify the API, then generate server interfaces (they call them stubs), and generate client libraries. Finally, you develop what goes on behind the interface on the server side, and (you or others) use the API on the client side. When I say “generate,” I mean “Tell it your favorite language, and click generate.” It spits out the code you can then use to flesh out your API. It does not spit out the info to get the API into your DevOps toolchain, so you’ll have to do the work for that. Which means the more APIs you can generate in a batch, the less DevOps lifting you’ll have to do (more on that if/when we cover microservices). Since most languages can easily be placed into DevOps via their build tools, I don’t want to make this sound too onerous – security and testing will be a bigger problem, by far.

API security is slowly getting automated and placed right into generated code, but all the usual bits, like certificate management, still have to be handled. The interesting thing, that hasn’t (yet) gotten a ton of attention, is security of clients. It is far harder to verify that the client library is secure when the purpose of that library is to grant access to your API. I expect we’ll eventually have to get there for some applications, but today, it appears to be largely individual orgs figuring out how best to lock down client libraries, and most of the limiting factors end up server-side.

I’ve generated Python, Java and Ruby APIs via various toolsets, and considering the problem domain is still relatively small, they work fine. And it saves one piece of the puzzle … but does introduce another piece – coordinating client and server updates via DevOps.

Keep making the apps that run the world, and use API generators to further standardization, spitting out whatever language you need on the backend, and a portable interface for clients.

Whatever your language of choice, in the end, it will likely be your build tool that links it to DevOps. Your biggest concern for DevOps will probably be portability, at least in the near future. Meanwhile, keep rocking it. You’re doing the work that needs doing, even if it isn’t the part of DevOps everyone is currently buzzing about.

Programming language rankings get regular headlines, and they should, at least from trend trackers like us. Among my favorite is the RedMonk quarterly, published this week. I like the methodology of their system, which extracts data from GitHub and Stack Overflow and combines them for “a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction.”

In other words, it correlates what the cool kids are talking about with actual language usage “in an effort to extract insights into potential future adoption trends.” It’s a mix that makes it meaningful.

The latest ranking was posted by veteran industry analyst Stephen O’Grady on his RedMonk blog. “GitHub and Stack Overflow are used here, first, because of their size, and second, because of their public exposure of the data necessary for the analysis,” he wrote.

O’Grady’s post includes thoughtful observations about JavaScript, TypeScript, Ruby, Go, R, Kotlin, Rust, and Dart.

There’s quite a lot of change afoot in the programming world, the analysts found, but constant has been the rise of Python, which has maintained its top ranking ahead of Java. “Java was extremely hot on Python’s heels – and was in fact closer to the number one ranking than to PHP behind it – but Python’s ability to defend its new high ranking is notable,” O’Grady wrote.

Half of the Top 20 languages experienced “a degree of movement,” O’Grady added, “which is very unusual. It’s difficult to attribute this definitively to any higher level macro trends, but the data is consistent with an industry that picked the pace back up in the last two quarters of the year after the initial chaos of lockdowns and so on gave way to livable if extremely suboptimal new routines.”

JavaScript is holding its own in the rankings. “[I]t is worth noting just how robust JavaScript’s performance remains,” O’Grady observed. “In spite of all of the competition from up and coming languages, all the discussion of fragmentation and even criticisms of JavaScript the language itself, it remains remarkably popular.

JavaScript pull requests are up 453% since Q1 of January of 2018, and they were up 96% from the last quarter “on an already massive base of commits.” ‘

‘Simply put, JavaScript remains – its detractors notwithstanding – a force of nature like no other within the industry,” he wrote, “and there are no indications in the data that this is likely to change any time soon.”

TypeScript, which is a superset of JavaScript, moved up for the sixth of its latest eight quarterly RedMonk rankings, “and its popularity is evident when one looks around the industry.” Ruby is on a gentle long-term downward trajectory, the analysts found. Go is slipping, too. R, a language for statistical computing and graphics, appears to be on a slow upswing. Both Kotlin and Rust showed signs of growing popularity. And Dart, an open source, purely object-oriented, optionally typed, and a class-based language, has risen since the advent of the Flutter framework.

Th RedMonk report surrounds a cool plotting of the language rankings with detailed analysis of key trends over the past quarter. As far as I’m concerned, it’s a must read.