Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
If you are bulding independent functionality with broadly different capabilities then deploying these capabilities as separate services makes sense. That is you need to organise Microservices based on what they do.
There is a danger that they can become based around objects in the domain. Each Microservice should have it's own resources such as databases. The idea is that they don't share common databases. To create separate services around individual domain objects will only make things less scalable.
My own approach has been a general purpose platform which is runtime configurable, much like a database server can have a runtime defined schema. We have made the platform application totally configurable from data objects to user interface. I've extended this all the way to the REST interfaces. This way any node in the cluster can service any call.
No worries about scaling up, just add more nodes to the cluster. Because any node services any call there are no service choke points. Because configuration is runtime there are no deployments. Business rules are adaptable, not burnt into the binary.
The same technology runs equally well on a single box and a distributed cluster. It also means that rather than huge IT teams you could start giving managers ownership and control over their own processes and applications.
What would be the boundaries of the problem this kind of platform would solve? Is it everything you could imagine, or the focus will still be in certain areas like software delivery automation, IoT, finances etc.?
In my opinion, a general-purpose platform would give more flexibility but at the same time it would require strict knowledge and expertise to define and represent the problem to be solved.
If you consider a SaaS that abstracts a great amount of complexity with delivering web applications or microservices on Kubernetes, for somebody to be able to do the same in a general-purpose platform would require a lot of time and expertise to make it work.
Usually, there are cases when somebody likes more flexibility and cases where somebody likes to focus primarily on building the business and leave other aspects to be solved by competent SaaS.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
The situation with this project is complicated. It is not an offering you can buy or something you can find in a public open source repo, at least not yet.
We don't yet have a system capable of creating fully rich business applications. There are some missing components to be considered a full application development platform, but it is being used to deliver multiple analytics applications. The trajectory is toward a business application development environment.
My experience so far is that you need designers with a good understanding of data and UI design. These designers don't need to know how to code, but they do need to know about databases, data transformations, how to set up visualizations and navigation. Once configured it has a elegant UI for the users.
Basically there are three tiers. There are the developers who maintain the core platform infrastructure. Then there are designers who configure applications who are not coders but who are skilled with the tool. Then there are users who simply use the finished applications.
I'm not keen to claim this a totally generic 'application development' system because I'm fully aware of the folly of such claims. It aims at business systems which work with textual data and business processes communicating with other systems and partners.
I know this might sound 'too good to be true', but it is founded on some hard won experience and good ideas from many people over several years. Hopefully one day I will be able to show everyone.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
This sounds like the 'scaled monolith' pattern, with the code/logic to handle any events available but not always used (configuration applies constraints) across a compute platform? The challenge (as expressed by @sarafian
) is in disciplined deployment and operational expertise, promoting configuration and config management (CMDB) to a first class citizen of the ecosystem (as it should be!).
Udi Dahan (course linked from my earlier comment), and others suggest that SOA (and by extension microservices) allow focused solutions to business problems to be created directly in custom code, rather than attempting to predict the future and develop a configuration-driven 'toolbox of capabilities' that makes others (typically consultants - see SAP!) responsible for understanding and solving business problems. I guess it depends what you are selling - the toolbox or the business outcomes ;)
Thank you Phil (@phlash909
). I personally find this aspect the most under considered in any topic in IT and only Fowler is one of the few people actually discussing it as part of the "solution". And the most funny thing is that these questions are primarily for the business people (set the business goals) and they refuse to engage and just consider it a technical "solution". But no solution exists to an undefined problem and therefore undefined expectations.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you are bulding independent functionality with broadly different capabilities then deploying these capabilities as separate services makes sense. That is you need to organise Microservices based on what they do.
There is a danger that they can become based around objects in the domain. Each Microservice should have it's own resources such as databases. The idea is that they don't share common databases. To create separate services around individual domain objects will only make things less scalable.
My own approach has been a general purpose platform which is runtime configurable, much like a database server can have a runtime defined schema. We have made the platform application totally configurable from data objects to user interface. I've extended this all the way to the REST interfaces. This way any node in the cluster can service any call.
No worries about scaling up, just add more nodes to the cluster. Because any node services any call there are no service choke points. Because configuration is runtime there are no deployments. Business rules are adaptable, not burnt into the binary.
The same technology runs equally well on a single box and a distributed cluster. It also means that rather than huge IT teams you could start giving managers ownership and control over their own processes and applications.
youtube.com/watch?v=uwZj4XF6zic
Interesting approach Peter, sounds catchy.
What would be the boundaries of the problem this kind of platform would solve? Is it everything you could imagine, or the focus will still be in certain areas like software delivery automation, IoT, finances etc.?
In my opinion, a general-purpose platform would give more flexibility but at the same time it would require strict knowledge and expertise to define and represent the problem to be solved.
If you consider a SaaS that abstracts a great amount of complexity with delivering web applications or microservices on Kubernetes, for somebody to be able to do the same in a general-purpose platform would require a lot of time and expertise to make it work.
Usually, there are cases when somebody likes more flexibility and cases where somebody likes to focus primarily on building the business and leave other aspects to be solved by competent SaaS.
The situation with this project is complicated. It is not an offering you can buy or something you can find in a public open source repo, at least not yet.
We don't yet have a system capable of creating fully rich business applications. There are some missing components to be considered a full application development platform, but it is being used to deliver multiple analytics applications. The trajectory is toward a business application development environment.
My experience so far is that you need designers with a good understanding of data and UI design. These designers don't need to know how to code, but they do need to know about databases, data transformations, how to set up visualizations and navigation. Once configured it has a elegant UI for the users.
Basically there are three tiers. There are the developers who maintain the core platform infrastructure. Then there are designers who configure applications who are not coders but who are skilled with the tool. Then there are users who simply use the finished applications.
I'm not keen to claim this a totally generic 'application development' system because I'm fully aware of the folly of such claims. It aims at business systems which work with textual data and business processes communicating with other systems and partners.
I know this might sound 'too good to be true', but it is founded on some hard won experience and good ideas from many people over several years. Hopefully one day I will be able to show everyone.
This sounds like the 'scaled monolith' pattern, with the code/logic to handle any events available but not always used (configuration applies constraints) across a compute platform? The challenge (as expressed by @sarafian ) is in disciplined deployment and operational expertise, promoting configuration and config management (CMDB) to a first class citizen of the ecosystem (as it should be!).
Udi Dahan (course linked from my earlier comment), and others suggest that SOA (and by extension microservices) allow focused solutions to business problems to be created directly in custom code, rather than attempting to predict the future and develop a configuration-driven 'toolbox of capabilities' that makes others (typically consultants - see SAP!) responsible for understanding and solving business problems. I guess it depends what you are selling - the toolbox or the business outcomes ;)
Thank you Phil (@phlash909 ). I personally find this aspect the most under considered in any topic in IT and only Fowler is one of the few people actually discussing it as part of the "solution". And the most funny thing is that these questions are primarily for the business people (set the business goals) and they refuse to engage and just consider it a technical "solution". But no solution exists to an undefined problem and therefore undefined expectations.