Hi Guys,
   Just thought I would throw this out for discussion..

   In the 'Old Days', i.e. 8080, z80, etc, assmebler code, we constantly tried to keep programs small, simple and fast.
There was only a limited amount of memory available.

   As hardware evolved and memory became cheaper, higher level languages evolved on/for the PC.  Basic, Cobol, Fortran,
Lisp, Forth, Modula2, C, C++, C#, Pascal, etc, etc.  They were able to work because there was memory and PC bandwidth
available.

   As a programmer of 40+, years having worked in all of the above languages at one time or another, I am wedded to the
notion of small, specific, fast, discrete, as guidelines for applications.  As such I tend to produce an Application
Suite of smaller Apps rather than one big, monolithic App.

   What's your view on monolithic v discrete?

Regards,
Ian

Ian


<<What's your view on monolithic v discrete?>>

Changeable

In the early days using APL on a supermicro (Motorola 68000 based) I ended up writing my own memory manager to swap stuff in and out of memory. Later using dBase III (well Clipper) I didn't worry when it reached a megabyte and allowed Windows to manage memory. These days - as an example I have a Seagate utility. All it dos is allow the timeout for their USB disks to be set and its 22Mb.

I tend to look more at probable frequency of use, convenience of use, and danger of use than program size. After all more memory is taken up by the registry than anything I could write!

Roy Lambert

Roy Lambert wrote:

> dBase III (well Clipper)

Hi Roy,
   Ahhh yes.  DB3 & Clipper.  How could I have forgotten them?  In fact the Grandfather, circa 1993, of the project that
just recently converted to EDB started as a DB3 App, then Clipper with the Successware SIX DOS .DBF engine, then to
Delphi with the Successware Windows .DBF engine, then to the ADS (.ADT) engine.  It is in fact still in
service/operation.
   
   I still have the source and build tools for it.
   
   Strangely I don't get many support calls for it these days but it's still working.  God knows how many records it
is working with now.  Must ask.  The last time I looked in April 2014 there were 78000 or so records.  Could be in the
90,000+ now.

Regards,
Ian

Roy Lambert wrote:

> Changeable

I agree - and partly because the world of software is changing a lot too. The desktop is now "dead" (same as the PC etc - it will last forever, but is not where the majority is going).

I've built lots of big applications (some still sold) and some which have been bunches of applications working together. And then the database side of things like N-Tier. But the world is now about "micro-services" and that's where my focus is, with either web or thin client applications providing the user interface. One of my clients has a bunch of such services that are all working together using interfaces to provide access to different aspects of things. An authentication service for example which allows user accounts, but can also use a legacy database, or a login database, and the caller need not know which.

It would be a special need I think to start a big desktop application today.

--

Matthew Jones

Ian,

<< As a programmer of 40+, years having worked in all of the above languages at one time or another, I am wedded to the notion of small, specific, fast, discrete, as guidelines for applications.  As such I tend to produce an Application Suite of smaller Apps rather than one big, monolithic App.

What's your view on monolithic v discrete? >>

The issue with smaller, discrete applications/services is that they increase the level of communication complexity, and, therefore, increase the failure surface quite a bit for every application/service that you add.

When you have one monolithic application server that handles everything, you lower the failure surface area.

https://genehughson.wordpress.com/2015/01/30/microservice-mistakes-complexity-as-a-service/

Think of it in terms of classes in Object Pascal: if you take a class interface (public/published) and push it out into a microservice, you are removing a) the ability to have the compiler type-check the interface (this *can* be ameliorated with RTTI and API bindings, but they're only as good as the information that they're given and can be broken on the service end at any time, especially if you are not in control of the service API), b) the ability to guard against network/communication failures that can cause cascading failures that take down the entire stack or seriously disrupt the operation of the business, and c) the ability to easily control transactional boundaries so that you aren't stuck engineering complex architectures involving compensating transactions, two-phase locking, etc..

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> https://genehughson.wordpress.com/2015/01/30/microservice-mistakes-complexity-as-a-service/

Hi Tim,
   Not sure about the Hamburger example.  It is working on the principle that those microservices must work/complete
every time before you can have your Hamburger.

   The context I work on is separating functional activities/roles for the applications.

   e.g.  One App works solely on booking in, management & booking out.  The life-cycle of the job.  Another App looks
after maintenance of support tables.  Another looks after backup and restore of the database.  Another facilitates
Report management and development.  Etc, etc.

   Whilst it could be argued that the second app in the above has to have done its thing before the first, once the
second app has completed its role it doesn't need to be called again in support of the first app unless there is a
change required to some support table.  Not every time the first app runs.

   I prefer this 'construction' rather than all the above functionality built into one large application.

   Horses for courses.

Regards,
Ian.

Ian,

<< The context I work on is separating functional activities/roles for the applications. >>

If the applications are functionally independent and don't rely on each other, or each other's data, then sure, you can separate them out without any issue.  That's always been the case.

But, as soon as any of them start having dependencies, watch out...

Tim Young
Elevate Software
www.elevatesoft.com