Hello everybody!
With the arrival of the server-less architectures, the general adoption of Cloud platforms and programming everything is changing fast. Where are we going to? 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:
This is the key part of this post, the creation of new roles in programming languages:
Producers build complex programming services encouraging the optimization of computing, parallel processes, performance, light footprint, strongly 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 makes necessary training and years of working to acquire decent skills. Good examples are:
C, C++, C#
Scala, Java
Go
and others..
On the other side, consumers are just weak programming pieces that expect that all the annoying stuff about multi-threading, parallel processes, non-blocking, etc is in charge of the PaaS or the Server-less platform that they are consuming. These languages are always interpreted, mono-thread, with a poor efficiency, poor performance and usually based on simple libraries as files. The learning curve is soft to allow a rapid acquisition basic skills. Productivity and speed are key aspects. Some examples are:
Python
JavaScript
Ruby
etc..
If this is good or bad, it 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, 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, the consumers are obligated to pay those new services they are subscribed, generating new elements in accountability, budget, etc.
Besides, as consumer languages are not usually useful to build complex PaaS 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 above image, in the Big Data-Machine/Deep Learning world the pattern producer/consumer 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 try. Yes, you can fail but what you learn in the way is invaluable and always will be more interesting that remaining in a primary programming level.
Thanks for your patience.
With the arrival of the server-less architectures, the general adoption of Cloud platforms and programming everything is changing fast. Where are we going to? 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:
- Server-less architectures, strongly based on Cloud platforms.
- Product as Services. Yes, strongly based on Cloud as well.
This is the key part of this post, the creation of new roles in programming languages:
- Consumers
- Producers
Producers build complex programming services encouraging the optimization of computing, parallel processes, performance, light footprint, strongly 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 makes necessary training and years of working to acquire decent skills. Good examples are:
C, C++, C#
Scala, Java
Go
and others..
On the other side, consumers are just weak programming pieces that expect that all the annoying stuff about multi-threading, parallel processes, non-blocking, etc is in charge of the PaaS or the Server-less platform that they are consuming. These languages are always interpreted, mono-thread, with a poor efficiency, poor performance and usually based on simple libraries as files. The learning curve is soft to allow a rapid acquisition basic skills. Productivity and speed are key aspects. Some examples are:
Python
JavaScript
Ruby
etc..
If this is good or bad, it 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, 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, the consumers are obligated to pay those new services they are subscribed, generating new elements in accountability, budget, etc.
Besides, as consumer languages are not usually useful to build complex PaaS 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 above image, in the Big Data-Machine/Deep Learning world the pattern producer/consumer 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 try. Yes, you can fail but what you learn in the way is invaluable and always will be more interesting that remaining in a primary programming level.
Thanks for your patience.
Comments
Post a Comment