This content is part of the Essential Guide: The vital guide to modern programming languages and their uses

The right language for microservice orchestration and development

As organizations create a microservices-based component architecture, many wonder which programming language to choose for microservice orchestration.

Nearly every software developer, architect and development manager is facing, yet again, the service-driven revolution in software. The service-oriented, component architectures are evolving to combine web, object-oriented and service-oriented architecture principles in one unified architecture, and it's natural to wonder how to select programming languages for new applications. The best approach is to start with the most popular languages to ensure you'll find qualified talent, separate plans for front-end and back-end development, think in terms of language-and-middleware ecosystems, look for explicit service and microservice orchestration support in languages, and think about modern stateless techniques in functional programming. While this order of consideration is helpful, all these issues end up being related.

When you're building a component architecture, whether you use a service or a microservice, you should think of it in context, meaning as a part of a workflow that will normally begin and end with a user. The service or microservice response time has to meet user expectations, the resources the service or microservice orchestration uses must be small enough to control deployment costs, and the service or microservice has to be secure and compliant with policies. Keep all these in mind when making your language choices.

The most popular programming languages for services and microservices are, in order, Java, C#, C, Ruby, Python and C++. If you have a strong commitment to one of the first three languages on this list, then that language is your presumptive choice for service or microservice development. Your only question will be whether to deviate from that presumption, either overall or for a specific service or microservice orchestration. If you have no such commitment, then you'll have to pick a development language based on service use and your overall IT process. In all these cases, be sure to use the latest version of the language. For Java this is particularly critical since Java 8 has significant advances in support for service or microservice development.

Getting started with microservice development and orchestration

Start your assessment with the role your service or microservice will play. Most modern applications are designed for web-GUI or app delivery and so divide naturally into a front-end and back-end architecture. Front-end-oriented services and microservices usually support information presentation and basic validation, and back-end processes define the business logic. There's a specific hand-off between the two application pieces. If your application divides this way, the best approach is to select your programming language and overall application architecture based on back-end needs. The front end should then conform.

The best back-end languages will probably be Java, C#, C or C++ because these languages are highly structured and efficient in execution and resources and have extensive libraries of business tools available. Services written in C or C++ are highly efficient in resource use and high in performance, but development is costly and changes often even more so. If you have a highly volatile set of requirements, rely on contract programmers, or if you have difficulty obtaining C or C++ skills locally, you may want to think more of Java or C#.

The most popular programming languages for services and microservices are, in order, Java, C#, C, Ruby, Python, and C++.

If you have a commitment in-house to Oracle's Java or Microsoft's C# or if you do your business application development in C or C++, you may want to consider doing your front-end development in a more web-friendly language like Ruby or Python. These languages can be used for front-end-related web services as well as for web or mobile backend as a service and they're easy to learn, use and change.

Evaluating microservice complexity

Now, go back to the application context or workflow itself. If you are developing a complex and highly integrated application to be supported by services or microservices, then consider one of the popular software ecosystems. Java is the most popular programming language today, and it has a rich collection of middleware tools for service construction or microservice orchestration. Java is also highly portable across operating systems and even processor hardware. It's fairly easy to read and develop in, and so it's often the presumptive choice for service or microservice development.

Microsoft shops should always consider the .NET middleware set. The default language for Microsoft development for services and microservices is C#, though some companies will also use Visual Basic. Remember that Microsoft's platform-as-a-service cloud, Azure, offers the same .NET support as Microsoft server software for the data center, so it's easy to build hybrid applications or to cloudburst from data center into Azure. Microsoft has strong support for both SOA and microservice development included in its middleware too.

Java, C#, C and C++ all have available middleware to facilitate component architecture development; users report that Ruby and Python have service and microservice support, but lack the range of easy-to-use middleware tools of the other languages. If middleware tools and universal support of hardware platforms and public cloud providers is the main consideration, Java is likely the best choice because it has a massive inventory of standard features for service and microservice development and also integrates well with data centers (Java Enterprise Edition).

Software development managers report that even with middleware and development tools, service and microservice development in C and C++ can be challenging. The problem is that good service and microservices practices these days are likely to preference RESTful, stateless interfaces to the services. Both C and C++ provide programmers with plenty of latitude in building software, and that can mean accidentally creating a service that retains variable values between accesses, which violates most best-practice definitions for services or microservices. If you plan service development in these languages, take time to review each service for hidden, stateful dependencies.

One trend that tries to reduce stateful behavior within the language is functional programming. In functional programming, programming language constraints reduce or eliminate the creation of what are called side effects, where the way a service is implemented accidentally creates stateful implementations or otherwise depends on the context of service requests. All of the languages described above have support for functional programming, but the approach each takes is different. With C and C++ there's considerably more onus on the architect and programmer to enforce functional discipline, where with the other languages there's a specific programming syntax that goes a long way toward enforcing functional behavior.

Many believe that functional programming is driven in part by the service or microservice trends that are changing component architecture and development practices overall. It's likely that not only will functional programming be enhanced over time, but that other features will be added to help build service-based applications. It's important for architects, developers and development managers to keep pace with the changes to enable creation of the best possible services for their business.

Next Steps

Move a microservice infrastructure off AWS in a weekend

Simplified messaging and microservice development with PHP's PSR-7

Elixir vs. Clojure for functional programming at scale

How viable is it to create microservices in Python?

A 7-point language comparison of Ballerina vs. Golang

Dig Deeper on Software development best practices and processes

App Architecture
Software Quality
Cloud Computing