If you want to increase the benefits that computing provides while reducing the costs associated with it, this game plan might help.
Save money on platforms.
Raw computing power is becoming ever cheaper. Unfortunately, utilizing it well seems to be getting ever more difficult.
How much cheaper? Computers have storage and processors. The storage is for describing objects (i.e., nouns.) The bigger, the better. Processors are for performing tasks (i.e., verbs.) The faster, the better. In 1958 I first wrote programs for the Sperry-Rand Univac 1. It was the first computer that became a product. Since then the costs have dropped by a factor of 127 trillion. A leader in this is the Raspberry Pi. The change works out to be about a 50% reduction every 16 months.
Linux and other free open source tools have further reduced platform costs.
Platform independence is key to lower computing costs.
Don't get locked in. A platform independent software tool or application can be made to easily run on a number of operating systems, computer hardware and system architectures. Platform independence keeps you from being locked into overly complex, unadaptable technology.
The applications newspapers use are large and feature rich. They can be built of components that share a common data store, e.g. an ad database. Alternatively, they can be composed of a set of tasks or services. Neither of these system architectures is guaranteed to minimize system complexity. Care must be taken to prevent being locked into a monolithic database. Components can become too complex when they have too many interacting functions.
A microservice architecture seems closer to the ideal. A system built of microservices has a service oriented architecture that follows certain rules. These rules are designed to minimize complexity and maximize adaptability. A less complex system will be easier and faster to extend, debug, upgrade, deploy, understand and support.
A microservice is a software component designed to perform a single function. Microservices are a way to build modular systems. Several rules characterize them. They have their own data. No microservice can directly access another or its data. (I.e., no shared databases, monolithic or otherwise.) Microservices can reside anywhere. Data is shared among microservices via an enterprise service bus. (ESB). ESBs use standard, encrypted protocols to provide communication among microservices. Only the ESB knows where a microservice resides, locally or network based.
A given function might be implemented by several different microservices. The ESB chooses which. For example, using the ESB an upgraded component can be tested in parallel with a prior version.
Well written microservices are inherently platform independent. Systems built with them are compatible with every type of system architecture from dedicated workstation to a single server, multiple servers, private clouds and hosted platforms.
Standby ads, an illustrative example:
Our advertising systems have supported standby (or remnant) ads for decades. If you are dummying a product and have a space you need to fill, putting in a standby ad can provide revenue where a regular filler would not.
Standby ads should not be ordered in the ad order entry system, because there is not yet an order. Supporting them within a microservice is a near perfect use case for them.
Up until recently we bound standby support into our display ad dummying system. If you had a space to fill while dummying, you could find an ad to use. Unhooking standbys proved a revelation. Using the standby ad microservice allows remnant ads to be selected during classified pagination as well. Isolating the function offered new revenue possibilities.
What is good for classified pagination is also good for news pagination. Well engineered microservices can often be easily used in many different contexts.
What makes for a good system architecture is well engineered software.
The best choice will be the least complex to do what's needed. You will know it by how durable it proves to be.