[HN Gopher] A unified theory of low/no code and middleware
___________________________________________________________________
A unified theory of low/no code and middleware
Author : makaimc
Score : 37 points
Date : 2021-05-07 11:19 UTC (1 days ago)
(HTM) web link (mslotnick.substack.com)
(TXT) w3m dump (mslotnick.substack.com)
| ignoramous wrote:
| I think the basic reason why low-code / no-code works is down to
| software bugs.
|
| Bugs are a function of number of engineers, features, moving
| parts, and significant lines of code.
|
| No-code takes out engineers, moving parts, and SLoC from the
| equation (as far as the enterprises buying these solutions are
| concerned), but leaves a lot to be desired in terms of feature
| set; low-code brings down number of engineers, and SLoC, whilst
| providing flexibility in terms of bespoke feature sets.
|
| Also, another reason is, in essence, No-code and Low-code are
| natural extension of the cloud computing model in which capex is
| traded away for opex. And economies of scale, over time ensures,
| Low-code / No-code is going to be cheaper yet more reliable than
| anything one (tech-enabled) enterprise can roll on their own.
| budibase wrote:
| For Budibase, we often hear enterprises talk about two reasons
| for their interest: Cost of devs Speed of delivery (leading to
| faster growth and operations)
| hughrr wrote:
| That's kind of funny. Back in the early 00's I built a big
| perl "engine" for an internal LOB platform which roughly
| looked like your product. The business built their apps on
| it. But neither me or the business saw the value in the
| platform on its own. Big fail - perhaps I could have been the
| original Salesforce.com or something...
| indymike wrote:
| You ought to have a look at the Zapier zapps our marketing team
| has created. Buggy, brittle, and just oh-so-better than
| nothing.
| gervwyk wrote:
| Well said. This is exactly what we find when building
| applications with Lowdefy [0]. Because we are writing
| applications in a "schema", implementations becomes more and
| more consistent. To the point where if I pick up an complex
| application written by a colleague, it takes me only minutes to
| understand what has been done and start contributing. In an
| enterprise space, this greatly reduces risk in project
| handover.
|
| Since the logic operators and ui blocks are consistent and
| tested across all apps, code errors reduces over versions. But
| implementation errors still exists. This normally happens
| because the app builder does not fully understand the
| application data.
|
| So by using a DSL we effectively reduce the moving parts. With
| the remaining problem being - does the developer understand the
| data - and as a business, this is where you want developers to
| spend their time to extract the most value.
|
| [0] - https://github.com/lowdefy/lowdefy
| zozbot234 wrote:
| Do we _really_ need all the bespoke middleware stuff that OP goes
| on and on about, when practically all new, greenfield
| applications are based in some way or another on the Web and its
| open protocols? What middleware is still needed, other than the
| well-known semantic web and linked-data standards that have been
| developed specifically so that disparate applications from many
| vendors would be enabled to interoperate via a common Web
| platform, while allowing for user-directed extension and
| customization?
| Closi wrote:
| The answer is 'yes, absolutely', particularly considering we
| are talking about Enterprise IT here.
|
| Take for instance a common integration point for these
| applications - sending a sales order to a warehouse management
| system (WMS). Even if both systems have RESTful API's there is
| no fixed standard for a sales order, so you need to at least do
| some mapping. Then maybe actually you find out WMS needs a
| reference from the transport management system that has to be
| merged into it, and this also has to go back to ERP (which
| isn't part of the standard 'send order' integration). This is
| why middleware programs exist.
|
| Enterprises often end up being bundles of random applications
| that all need to be informed about random stuff, and it's just
| not practical to expect the application vendors to know what
| applications need to be aware/informed of what.
| osullip wrote:
| All I do for a living is build middleware.
|
| Don't take that away from me.
| zozbot234 wrote:
| This kind of mapping and data massaging is a comparatively
| manageable task _if_ the applications themselves provide
| reasonably standard interfaces. There 's no inherent reason
| for it to be provided out-of-the-box by a single, monolithic
| "middleware" platform.
| Closi wrote:
| If you are a large business the assumption that all
| applications will have reasonably standard interfaces won't
| hold water.
|
| Most ERP's or similar enterprise software will have some
| sort of mapping layer (e.g. mulesoft) otherwise they just
| won't be able to roll their software out into the real
| world.
| zozbot234 wrote:
| It's at least no worse than "all applications will be
| compatible with a single, proprietary middleware
| platform", which is the assumption OP seems to rely on
| for their argument that these bespoke platforms are so
| crucial to enterprise IT.
| Closi wrote:
| The middleware platform is about applications
| communicating to/from _salesforce_ , or the ERP, or
| whatever the application is.
|
| Let's say we have the following:
|
| _- Salesforce conforms to a standard and sends sales
| orders in format "Generic Order Format"
|
| _- WMS receives sales orders in format "WMS Order Format"
|
| _- TMS receives sales orders in format "TMS Order
| Format"
|
| _- TMS will update Salesforce on shipment progress in
| format "TMS Order update format"
|
| *- WMS will also update shipment progress to Salesforce
| in "WMS Order update format"
|
| So without some sort of mapping layer, how would this
| work? Insisting the other vendors change their software
| to conform to "Generic Order Format" is just moving the
| issue, and means you will never make any sales.
| Closi wrote:
| A really good post - I think 'low/no' code generally gets a hard
| time on HackerNews, generally because it's place and application
| is misunderstood.
|
| The success of PowerApps is a huge part of the Microsoft Dynamics
| appeal in the ERP space for instance - and they seem to be
| winning this segment very quickly on the back of it with
| tremendous growth.
|
| The fact a relatively inexperienced user can create a new phone
| app that is fully integrated into the company ERP is a real point
| of difference.
| thrower123 wrote:
| I would rather write Spring beans or jam forks in my hand than
| try to glom Flow/PowerAutomate lego blocks together. When I
| have managed to staple together a workflow, it routinely stops
| working after a couple weeks.
|
| It's going to keep a lot of people employed keeping those
| things going as the platform shifts underneath you every six
| months, and/or yanking the Goldberg machines out into real
| code.
| [deleted]
| darkhorse13 wrote:
| That's what you would do because you can actually do it. But
| these tools are for people who don't know how to build those
| apps by writing actual code.
| zozbot234 wrote:
| The point of "writing actual code" is that it's the _only_
| way we know about of managing even middling amounts of
| complexity. If you "don't know how to do that", you
| _shouldn 't_ be attempting that sort of deployment in the
| first place. It's just not going to be sustainable.
|
| There are ways of writing _less_ code over time, but they
| 're based on the sort of solid abstractions that are really
| not that common. (This is how "high level" coding works.)
| But the typical "low code" or "no code" system is not built
| like that.
| gervwyk wrote:
| Totally agree with this. For example hiding config in a
| GUI creates an excessive amount to problems at scale. The
| magic of find, replace, cope and paste is at the core of
| why code works well at scale.
|
| Writing less code should always be top of mind for any
| developer. But making the right abstraction decisions
| seems to be the true art of coding.
|
| The question then becomes can we write a low code
| framework that does this well? - best we try :)
| Closi wrote:
| Too much of the conversation ends up being about 'low
| code' vs 'writing actual code', but this is like arguing
| about if a hammer or a welding torch is a better tool.
|
| The reality is that some problems are fundamentally
| better suited to low code, and the solutions will be much
| simpler and easier to maintain if they are built as low-
| code (e.g. if I have MS Dynamics and want a new data-
| entry screen, doing it as a model-driven PowerApp is
| undeniably the best way to do this).
|
| Other problems will either be too complex, a poor fit, or
| simply not possible to implement within low-code tools.
| I'm not going to start developing a mobile game in
| PowerApps!
|
| I think the overall issue is "If all you have is a
| hammer, everything looks like a nail". The best thing is
| to recognise the relative strengths and weaknesses of the
| two approaches and pick the right tool for the job.
| zozbot234 wrote:
| > a new data-entry screen
|
| We used to call those data entry screens "HTML forms".
| And hey, they're even text based so you can commit them
| to a version control!
| q-big wrote:
| > and the solutions will be much simpler and easier to
| maintain if they are built as low-code (e.g. if I have MS
| Dynamics and want a new data-entry screen, doing it as a
| model-driven PowerApp is undeniably the best way to do
| this).
|
| Counterexample: MS Access apps are often a maintenance
| nightmare.
___________________________________________________________________
(page generated 2021-05-08 23:00 UTC)