Skip to main content

How to select a programming model for your enterprise software development

Microservices hype is not over yet. There are technologies like serverless computing and multi cloud platforms coming up and they will eventually increase the need for microservices style programming and application development. When it comes to enterprise software development, we can see that it is a mixture of traditional soa style systems, api driven systems which are backed my microservices or above mentioned soa systems, cloud based SaaS applications as well as proprietary software systems running on premise. Enterprise is going to be like this for a foreseeable future.
It is quite important that as an architect or a senior leader who is responsible for an enterprise software architecture to understand the proper approach to built your software eco system which will be an ever important factor to your business. When it comes to building such a complex system, there are 3 main approaches stands out
  • Polyglot programming model
  • Platform based programming model (open source)
  • Vendor specific programming model (proprietary software)
Let’s talk about each of these approaches in detail.
Polyglot programming model
The rationale behind this model is that you allow your development teams to choose the best programming language or technology to build the systems which they are building. In a microservices type architecture, this freedom is automatically there since each microservice is independent from the other. It provides more agility and maximum usage of internal talents. With the invention of cross platform tools like docker, you can bundle your applications in a common wrapper and deploy them like they have developed with the same technology. The main disadvantage of this model is that scattered knowledge and too many tools and techniques in the platform makes it complex to manage under a single platform. But this gives the maximum flexibility when it comes to selecting the best technology for a given task. Most of the architects and senior leaders are afraid to go with this approach due to the fact that they cannot build enough expertise on all different technologies.
Platform based programming model (open source)
Instead of selecting a technology per each and every application, you can select a technology platform which will cater most of your application development requirements. When it comes to selecting such a platform, we need to consider the following capabilities of the platform.
  • Stability
  • Extendibility
  • Performance
  • Maintainability
  • Transparency
Open source technology platforms have become the defacto standard of choice for platform driven use cases. All the above mentioned factors are well covered with a proper open source technology platform. Some of the most popular open source technology platforms for building open source based enterprise applications are
  • Spring framework
  • Kubernetes
  • Docker
  • Netflix OSS
  • WSO2 Open source platform
This model provides advantages like easy maintenance due to common technology platform, easier to build in house expertise, less complexity and more stability. Based on the platform you choose to build your system, you can achieve goals like agility through this model.
Vendor specific programming model
This model of programming has been the choice in the past when there were few companies building enterprise software platforms. These large corporations built their own proprietary platforms and provided easy to use user interface driven tools to program their systems. No one knew how to debug these systems and what is happening under the hood and there were no open information about future road maps of these platforms.
Even though these platforms are proprietary and hard to debug, they have their own advantages.
  • Ease of use
  • Better stability
  • Purposely built software with quality features
One of the main disadvantages of this model is the lack of flexibility and vendor locking. Once you locked in, you don’t have a choice than pay what the vendor demands when you want to add a new feature. Sometimes, they will not add the relevant feature at all.
Conclusion
The 3 programming models described above have their own advantages and disadvantages based on your requirements and capabilities. Therefore, you need to weigh in all the factors before deciding on a specific approach.
Labels:

Comments

  1. Emily AndersonApril 15, 2024 at 9:43 PM

    Thanks for sharing this valuable information. If you are looking for enterprise software development services visit our website today.

    ReplyDelete
  2. AnonymousNovember 18, 2024 at 4:43 AM

    Custom enterprise software development offers a powerful way to transform businesses. By tailoring solutions to specific needs, organizations can achieve greater efficiency, productivity, and competitive advantage. By carefully selecting a development partner and following a well-defined process, businesses can ensure the successful implementation of custom software that drives growth and innovation. Enterprise software development

    ReplyDelete

Post a Comment

Popular posts from this blog

How to protect your APIs with self contained access token (JWT) using WSO2 API Manager and WSO2 Identity Server

In a typical enterprise information system, there is a high chance that people will use different types of systems built by different vendors to implement certain types of functionalities. The APIs might be hosted in an API Manager developed by vendor A and the user management can be implemented using a different vendor (vendor B). In this type of a situation, one system will not be able to directly contact the other system but they want to use both systems in tandem. Self-contained access tokens are used in these types of situations where applications can get the token from one system and use that in another system to access protected resources. In this scenario, the second system does not need to make a contact to the first system over the network to validate the user information since the token is self-contained and it has relevant details about the user. This will improve the token processing time significantly since it completely removes the network interaction. The below fig...
1 comment
Read more

WSO2 ESB creating a response for a "GET" request

When you are creating REST APIs with WSO2 ESB, you may need to send some response message back to the user when something goes wrong. In this kind of scenario, you can create a payload inside the ESB and send it back. For doing this, you can use the below configuration. <api xmlns=" http://ws.apache.org/ ns/synapse " name="LoopBackProxy" context="/loopback">    <resource methods="POST GET">       <inSequence>          <property name="NO_ENTITY_BODY" scope="axis2" action="remove"></property>          <log level="full"></log>          <payloadFactory media-type="xml">             <format>                <m:messageBeforeLoopBack xmlns:m=" http://services...
Post a Comment
Read more

WSO2 ESB usage of get-property function

What are Properties? WSO2 has a huge set of mediators but property mediator is mostly used mediator for writing any proxy service or API. Property mediator is used to store any value or xml fragment temporarily during life cycle of a thread for any service or API. We can compare “Property” mediator with “Variable” in any other traditional programming languages (Like: C, C++, Java, .Net etc). There are few properties those are used/maintained by ESB itself and on the other hand few properties can be defined by users (programmers). In other words, we can say that properties can be define in below 2 categories: ESB Defined Properties User Defined Properties. These properties can be stored/defined in different scopes, like: Transport Synapse or Default Axis2 Registry System Operation Generally, these properties are read by get-properties() function. This function can be invoked with below 2 variations. get-property(String propertyName) get-property(String scop...
Post a Comment
Read more