Programming Languages: Producers and Consumers

Hello everybody!

With the arrival of serverless architectures and the general adoption of cloud platforms, everything is changing fast. Where are we going? That is a good question, indeed.

Old school programmers feel comfortable with servers. Servlet containers, application servers, database servers, whatever. On the other side, new programmers try to rapidly write scripts to be executed in specific platforms, focused on requirements and keeping apart classical key aspects in programming like scalability, multi-threading, etc. It seems that there are two new patterns that are directly threatening the server paradigm:

• Serverless architectures, strongly based on cloud platforms.
• Products as Services. Well, strongly based on the cloud as well.

The primary result of these patterns is that we do not need (apparently) strongly typed languages managing threads, trying to compute processes in parallel, and all that stuff. Because the way we'll use the serverless architectures of a PaaS is not as partners or pair developers, but as CONSUMERS.

This is the key part of this post, the creation of new roles in programming languages:

• Consumers
• Producers

Producers are the languages to create PaaS and/or serverless-based systems. These new systems are based on offering different services and functionalities by subscription. To consume these services, you will need some weak programmatic tool that is just consuming what the PaaS or the serverless system are offering.

Producers build complex programming services, encouraging the optimization of computing, parallel processes, performance, light footprints, strong typing, etc. These languages are always compiled for optimization and can be OOP-, RFP-, or FOP-oriented. Usually, they have a strong learning curve that requires training and years of work to acquire decent skills. Good examples are:

• C, C++, C#
• Scala, Java
• Go, Elixir

On the other side, Consumers are weak programming pieces that expect that all the annoying stuff about multi-threading, parallel processes, non-blocking, etc. falls under the responsibility of the PaaS or the serverless platform that they are consuming. These languages are always interpreted, mono-thread, with poor efficiency, poor performance and usually based on simple libraries as files. The learning curve is lower, allowing a rapid acquisition basic skills. Productivity and speed are key aspects. Some examples are:

• Python
• JavaScript
• Ruby

If this is good or bad depends on how you see yourself as a programmer or your company in the market. As a mere consumer — being the client of external providers and being focused on the business logic — or as a producer, building capable systems that... you can sell to consumers as services.

Because an interesting conclusion of this difference is that consumers are obligated to pay for those new services they are subscribed, generating new elements in accountability, budget, etc.

Besides, as consumer languages are not usually useful to building complex PaaS, it can be dangerous to be excessively focused on them. You can be too dependent on external services and you'll be able to create consumers for them.

Regarding the above image, in the Big Data-Machine/Deep Learning world, the producer/consumer pattern is usual. For instance, notebooks are actually a fast way to develop scripts that will consume complex services in a platform (e.g. Hadoop, Spark, Tensor Flow). This is ideal to meet the Big Data paradigm of "Bring your code to data, not your data to the code."

Obviously, each option has different pros and cons. Money, time to business, objectives, skills of programmers, etc.

From my personal point of view, the best option is always supporting the most complicated thing you can. Yes, you can fail, but what you learn in the way is invaluable and will always be more interesting than remaining in a primary programming level.

Thanks for your patience.