Businesses discover that cloud computing isn't magic

Businesses are now (just now, after more than a decade of cloud computing) discovering that cloud computing is not magic. That it doesn't make their computing cheap. That it doesn't solve their problems.

Some folks have already pointed this out. Looking back, it seems obvious: If all you have done is move your web-based system into cloud-based servers, why would things change? But they miss an important point.

Cloud computing is a form of computing, different from web-based applications and different from desktop applications. (And different from mainframe batch processing of transactions.)

A cloud-based system, to be efficient, must be designed for cloud computing. This means small independent services reading and writing to databases or other services, and everything coordinated through message queues. (If you know what those terms mean, then you understand cloud computing.)

Moving a web-based application into the cloud, unchanged, makes little sense. Or as much sense as moving a desktop-based application (remember those?) such as Word or Excel into the web, unchanged.

So why use cloud computing?

Cloud computing's strengths are redundancy, reliability, and variable power. Redundancy in that a properly designed cloud computing system consists of multiple services, each of which can be hosted on multiple (as in more than one per service) servers. If your system contains a service to perform address validations, that service could be running on one, two or seven different servers. Each instance does the same thing: examine a mailing address and determine the canonical form for that address.

The other components in your system, when they need to validate or normalize an address, issue a request to the validation service. They don't care which server handles the request.

Cloud systems are reliable because of this redundancy. A traditional web-based service would have one address validation server. If that server is unavailable, the service is unavailable for the entire system. Such a failure can lead to the entire system being unavailable.

Cloud systems have variable power. They can create additional instances of any of the services (including our example address validation service) to handle a heavy workload. Traditional web services, with only one server, can see slow response times when that server is overwhelmed with requests. (Sometimes a traditional web system would have more than one server for a service, but the number of servers is fixed and adding a server is a lengthy process. The result is the same: the allocated server or servers are overwhelmed and response time increases.)

Cloud services eliminate this problem by instantiating servers (and their services) as needed. When the address validation server is overwhelmed, the cloud management software detects it and "spins up" more instances. Good cloud management software works in the other direction too, shutting down idle instances.

Those are the advantages of cloud systems. But none of them are free; they all require that you build your system for the cloud. That takes effort.

Low code and no code still require thinking

One of the latest fads in tech is the "low code" (sometimes called "no code") approach to application development. This approach lets one construct an application without programming. The implication is that anyone can do it, and that one does not need to study programming or hire a programmer.

In a sense, all of this is true. And yet, it is not quite true.

Nor is it new.

Let's look at the "low code is really old" idea.

We have seen "low code" development for decades. It comes and goes, a cycle almost in sync with cicadas (which emerge from the ground every seventeen years).

It has been called different things in the past: "Report Program Generator", "Powerbase", "Fourth Generation Languages", and possibly even "COBOL" (which was hawked as a way for managers and non-programmers to read -- although not write -- code).

Each incarnation of low-code solutions uses contemporary technology, and always uses mid-grade, generally available hardware. The idea is to make these solutions available to everyone, or at least a large portion of the population, and not require expensive or specialized equipment. The 2020 version of "low code development" includes cloud-based, web-based, multiuser applications that run on servers and are accessed by a web browser.

There are multiple vendors offering different solutions. Some solutions are little more than multi-user spreadsheets with templates for data entry and charts. Others are more sophisticated. But all share a common trait, one that has been in all low-code solutions over time: they build what they build, with little room for expansion or customization. Low-code solutions offer a room with walls, and you can move anywhere in that room -- until you reach a wall.

(Tech-savvy folks will observe that *all* programming solutions, including the high-end hardware and sophisticated programming languages, are "rooms with constraining walls". Computers are not infinite, nor are compilers, processors, and databases. You can do only so much, and then you must stop. All programming methods, high-code and low-code, have limits. But the low-code methods have more restrictive limits.)

My complaint is not about the limits, though. My complaint is about the unstated assumption that anyone can quickly build an application.

Any programming solution, high-code or low-code, requires more than programming. It requires an understanding of the data, and that data is used within the organization. It requires that the person building the application know the range of data values, the properties of individual data elements, and the ways in which those elements can be combined.

In other words, you still have to know what you want to do, you have to understand your data, and you have to think. Even for a low-code solution. Building a solution without the proper analysis and thought can lead to the wrong solution.

Low-code solutions are good for simple tasks, when those tasks are well-defined, have few (or no) exceptions, and do not have high performance requirements.

The high-code solutions require more planning and more coding (of course!), but offer greater expansion capabilities and more customization. You can detect specific conditions and add special processing for unusual cases. High-code languages also offer support for performance analysis such as profiling. 

Another unstated assumption is that once you have built your solution (low-code or otherwise), you are done. Experienced programmers know that programs and systems are not static, that they grow over time as people think of new uses for them. Low-code solutions tend to have little headroom, little upward potential. (They do what they do, and no more.) High-code solutions can be built in ways that let them expand easily, but such expansion is not guaranteed. I have seen any number of custom, high-code solutions that could not expand to meet the growing demands of the business.

Low-code generating systems have a place in the world. One can argue that spreadsheets are the extreme in low-code solutions (if we omit the macros written in VBA). Yet even spreadsheets require us to understand the data.

Selecting a low-code solution over a high-code solution is about trade-offs: ease-of-use (for the low-code solutions) against expansion and tuning (in the high-code solution). Which is better for you will depend on the task at hand, the people you have and their skills, and the future uses of the data and the developed system.

I favor simplicity, and consider solutions in terms of their complexity. I try to use the simplest technology for the solution,

First, consider using a spreadsheet. If a spreadsheet will handle the data and do what you need, use it.

Second, consider a low-code solution. If a low-code app will handle the data and do what you need, use it.

Finally, consider a high-code solution. If the simpler solutions don't do what you need, use the high-code solution.

But think about what you need, about your data, and about the limits on different solutions.

Then decide.

Three levels of Python programming

Python programming is not always what we think it is. I now think of Python programming as having three levels, three distinct forms of programming.

The first level is what we typically think of as programming in Python. It is writing Python code. This is the impression one gets when one has an "introduction to Python" class. The first program of "Hello, World" is written in Python, as are the successive programs in the class. Programs become more complex, with the addition of functions and later classes to organize larger and larger programs.

In this level, all of the code is Python. It is Python from top to bottom. And it works, for simple applications.

For some applications, it is not "Python all the way down". Some applications are complex. They must manage large quantities of data, and perform a significant number of calculations, and they must do it quickly. A Python-only solution is not a satisfactory solution, because Python is interpreted and slow.

At this point, programmers include carefully-constructed modules that perform calculations quickly. The modules "numpy" and "scipy" are the common modules, but there are many.

This is the second level of programming in Python. It is not often thought of as "programming in Python" or even "programming". It is more often though of as "importing modules and using the classes and functions in those modules".

That mindset makes sense. This work is less about Python and more about knowing which modules are available and which functions they provide. The task of programming is different; instead of writing all of the code, one assembles a solution from pre-packaged modules and uses Python to connect the various pieces.

That is why I think of it as a second level of programming. It is a different type of programming, a different type of thinking. It is not "how can I write code?" but instead "what existing code will perform this computation?".

Which brings us to the third level.

The third level of Python programming is building your own module. The existing Python modules, if they do what you need, are fast and effective. But if they do not do what you need, then they are not helpful.

Writing your own solution in Python will result is a slow program -- perhaps unacceptably slow. Therefore, as a last resort, one writes one's own module (in C or C++) and imports it into the main Python program.

This is, purists will argue, programming not in Python but in C or C++. They have a point -- it is writing C or C++ code.

But when the objective is to build a system to perform a specific task, and the top layer of the application is written in Python, then one can argue that the C code is merely an extension of the same application.

Or, one can think of the task as creating a system in multiple modules and multiple languages, not a single program in a single programming language, and using the best language for each piece of the system.

Python programming (or systems development) is often less about coding in a particular language and more about solving problems. With Python, we have three levels at which we can solve those problems.

Don't shoot me, I'm only the OO programming language!

There has been a lot of hate for object-oriented programming of late. I use the word "hate" with care, as others have described their emotions as such. After decades of success with object-oriented programming, now people are writing articles with titles like "I hate object-oriented programming".

Why such animosity towards object-oriented programming? And why now? I have some ideas.

First, we have the age of object-oriented programming (OOP) as the primary paradigm for programming. I put the acceptance of OOP somewhere after the introduction of Java (in 1995) and before Microsoft's C# and .NET initiative (in 1999), which makes OOP about 25 years old -- or one generation of programmers.

(I know that object-oriented programming was around much earlier than C# and Java, and I don't mean to imply that Java was the first object-oriented language. But Java was the first popular OOP language, the first OOP language that was widely accepted in the programming community.)

So it may be that the rejection of OOP is driven by generational forces. Object-oriented programming, for new programmers, has been around "forever" and is an old way of looking at code. OOP is not the shiny new thing; it is the dusty old thing.

Which leads to my second idea: What is the shiny new thing that replaces object-oriented programming? To answer that question, we have to answer another: what does OOP do for us?

Object-oriented programming, in brief, helps developers organize code. It is one of several techniques to organize code. Others include Structured Programming, subroutines, and functions.

Subroutines are possibly the oldest techniques to organize code. They date back to the days of assembly language, when code that was executed more than once was called with a "branch" or "call" or "jump subroutine" opcode. Instead of repeating code (and using precious memory), common code could be stored once and invoked as often as needed.

Functions date back to at least Fortran, consolidating common code that returns a value.

For two decades (from the mid 1950s to the mid-1970s), subroutines and functions were the only way to organize code. In the mid-1970s, the structured programming movement introduced an additional way to organize code, with IF/THEN/ELSE and WHILE statements (and an avoidance of GOTO). These techniques worked at a more granular level that subroutines and functions. Structured programming organized code "in the small" and subroutines and functions organized code "in the medium". Notice that we had no way (at the time) to organize code "in the large".

Techniques to organize code "in the large" did come. One attempt was dynamic-linked libraries (DLLs), introduced with Microsoft Windows but also used by earlier operating systems. Another was Microsoft's COM, which organized the DLLs. Neither were particularly effective at organizing code.

Object-oriented programming was effective at organizing code at a level higher than procedures and functions. And it has been successful for the past two-plus decades. OOP let programmers build large systems, sometimes with thousands of classes and millions of lines of code.

So what technique has arrived that displaces object-oriented programming? How has the computer world changed, that object-oriented programming would become despised?

I think it is cloud programming and web services, and specifically, microservices.

OOP lets us organize a large code base into classes (and namespaces which contain classes). The concept of a web service also lets us organize our code, in a level higher than procedures and functions. A web service can be a large thing, using OOP to organize its innards.

But a microservice is different from a large web service. A microservice is, by definition, small. A large system can be composed of multiple microservices, but each microservice must be a small component.

Microservices are small enough that they can be handled by a simple script (perhaps in Python or Ruby) that performs a few specific tasks and then exits. Small programs don't need classes and object-oriented programming. Object-oriented programming adds cost to simple programs with no corresponding benefit.

Programmers building microservices in languages such as Java or C# may feel that object-oriented programming is being forced upon them. Both Java and C# are object-oriented languages, and they mandate classes in your program. A simple "Hello, world!" program requires the definition of at least one class, with at least one static method.

Perhaps languages that are not object-oriented are better for microservices. Languages such as Python, Ruby, or even Perl. If performance is a concern, the compiled languages C and Go are available. (It might be that the recent interest in C is driven by the development of cloud applications and microservices for them.)

Object-oriented programming was (and still is) an effective way to manage code for large systems. With the advent of microservices, it is not the only way. Using object-oriented programming for microservices is overkill. OOP requires overhead that is not helpful for small programs; if your microservice is large enough to require OOP, then it isn't a microservice.

I think this is the reason for the recent animosity towards object-oriented programming. Programmers have figured out the OOP doesn't mix with microservices -- but they don't know why. They fell that something is wrong (which it is) but they don't have the ability to shake off the established programming practices and technologies (perhaps because they don't have the authority).

If you are working on a large system, and using microservices, give some thought to your programming language.

Optimizing in the wrong direction

Back in the late 200X years, I toyed with the idea of a new version control system. It wasn't git, or even git-like. In fact, it was the opposite.

At the time, version control was centralized. There was a single instance of the repository and you (the developer) had a single "snapshot" of the files. Usually, your snapshot was the "tip", the most recent version of each file.

My system, like other version control systems of the time, was a centralized system, with versions for each file stored as 'diff' packages. That was the traditional approach for version control, as storing a 'diff' was smaller than storing the entire version of the file.

Git changed the approach for version control. Instead of a single central repository, git is a distributed version control system. It replicates the entire repository in every instance and uses a sophisticated protocol to synchronize changes across instances. When you clone a repo in git, you get the entire repository.

Git can do what it does because disk space is now plentiful and cheap. Earlier version control systems worked on the assumption that disk space was expensive and limited. (Which, when SCCS was created in the 1970s, was true.)

Git is also directory-oriented, not file-oriented. Git looks at the entire directory tree, which allows it to optimize operations that move files or duplicate files in different directories. File-oriented version control systems, looking only at the contents of a single file at a time, cannot make those optimizations. That difference, while important, is not relevant to this post.

I called my system "Amnesia". My "brilliant" idea was to, over time, remove diffs from the repository and thereby use even less disk space. Deletion was automatic, and I let the use specify a set of rules for deletion, so important versions could be saved indefinitely.

My improvement was based on the assumption of disk space being expensive. Looking back, I should have known better. Disk space was not expensive, and not only was it not expensive it was not getting expensive -- it was getting cheaper.

Anyone looking at this system today would be, at best, amused. Even I can only grin at my error.

I was optimizing, but for the wrong result. The "Amnesia" approach reduced disk space, at the cost of time (it takes longer to compute diffs than it does to store the entire file), information (the removal of versions also removes information about who made the change), and development cost (for the auto-delete functions).

The lesson? Improve, but think about your assumptions. When you optimize something, do it in the right direction.

Slack, efficiency, and choice

Slack is the opposite of efficiency. Slack is excess capacity, unused space, extra money. Slack is waste and therefore considered bad.

Yet things are not that simple. Yes, slack is excess capacity and unused space. And yes, slack can be viewed as waste. But slack is not entirely bad. Slack has value.

Consider the recent (infamous) overbooking event on United Airlines. One passenger was forcibly removed from a flight to make room for a United crew member (for another flight, the crew member was not working the flight of the incident). United had a fully-booked flight from Chicago to Louisville and needed to move a flight crew from Chicago to Louisville. They asked for volunteers to take other flights; three people took them up on the offer, leaving one seat as an "involuntary re-accommodation".

I won't go into the legal and moral issues of this incident. Instead, I will look at slack.

- The flight had no slack passenger capacity. It was fully booked. (That's usually a good thing for the airline, as it means maximum revenue.)

- The crew had to move from Chicago to Louisville, to start their next assigned flight. It had to be that crew; there was no slack (no extra crew) in Louisville. I assume that there was no other crew in the region that could fill in for the assigned crew. (Keep in mind that crews are regulated as to how much time they can spend working, by union contracts and federal law. This limits the ability of an airline to swap crews like sacks of flour.)

In a perfectly predictable world, we can design, build, and operate systems with no slack. But the world is not perfectly predictable. The world surprises us, and slack helps us cope with those surprises. Extra processing capacity is useful when demand spikes. Extra money is useful for many events, from car crashes to broken water heaters to layoffs.

Slack has value. It buffers us from harsh consequences.

United ran their system with little slack, was subjected to demands greater than expected, and suffered consequences. But this is not really about United or airlines or booking systems. This is about project management, system design, budgeting, and just about any other human activity.

I'm not recommending that you build slack into your systems. I'm not insisting that airlines always leave a few empty seats on each flight.

I'm recommending that you consider slack, and that you make a conscious choice about it. Slack has a cost. It also has benefits. Which has the greater value for you depends on your situation. But don't strive to eliminate slack without thought.

Examine. Evaluate. Think. And then decide.

Locking mistakes on web pages

As a professional in the IT industry, I occasionally visit web sites. I do so to get information about new technologies and practices, new devices and software, and current events. There are a number of web sites that provide a magazine format of news stories. I visit more than IT web sites; I also read about social, political, and economic events.

I find many stories informative, some pertinent, and a few silly. And a find a number of them to contain errors. Not factual errors, but simple typographic errors. Simple errors, yet these errors should be obvious to anyone reading the story. For example, a misspelling of the name 'Boston' as 'Botson'. Or the word 'compromise' appearing as 'compromse'.

Spelling errors are bad enough. What makes it worse is that they remain. The error may be on the web site at 10:00 in the morning. It is still there at 4:00 in the afternoon.

A web page is run by a computer (a web server, to be precise). The computer waits for a request, and when it gets one, it builds an HTML page and sends back the response. The HTML page can be static (a simple file read from disk) or dynamic (a collection of files and content merged into a single HTML file). But static or dynamic, the source is the same: files on a computer. And files can be changed.

The whole point of the web was to allow for content to be shared, content that could be updated.

Yet here are these web sites with obviously incorrect content. And they (the people running the web sites) do nothing about it.

I have a few theories behind this effect:

• The people running the web site don't care
• The errors are intentional
• The people running the site don't have time
• The people running the site don't know how

It's possible that the people running the web site do not care about these errors. They may have a cavalier attitude towards their readers. Perhaps they focus only on their advertisers. It is a short-sighted strategy and I tend to doubt that it would be in effect at so many web sites.

It's also possible that the errors are intentional. They may be made specifically to "tag" content, so that if another web side copies the content then it can be identified as coming from the first web site. Perhaps there is an automated system that makes these mistakes. I suspect that there are better ways to identify copied content.

More likely is that the people running the web site either don't have time to make corrections or don't know how to make corrections. (They are almost the same thing.)

I blame our Content Management Systems. These systems (CMSs) manage the raw content and assemble it into HTML form. (Remember that dynamic web pages must combine information from multiple sources. A CMS does that work, combining content into a structured document.)

I suspect (and it is only a suspicion, as I have not used any of the CMS systems) that the procedures to administrate a CMS are complicated. I suspect that CMSs, like other automated systems, have grown in complexity over the years, and now require deep technical knowledge.

I also suspect that these web sites with frequent typographical errors are run with a minimal crew of moderately skilled people. The staff has enough knowledge (and time) to perform the "normal" tasks of publishing stories and updating advertisements. It does not have the knowledge (and the time) to do "extraordinary" tasks like update a story.

I suspect the "simple" process for a CMS would be to re-issue a fixed version of the story, but the "simple" process would add the fixed version as a new story and not replace the original. A web site might display the two versions of the story, possibly confusing readers. The more complex process of updating the original story and fixing it in the CMS is probably so labor-intensive and risk-prone that people judge it as "not worth the effort".

That's a pretty damning statement about the CMS: The system is too complicated to use to correct content.

It's also a bit of speculation on my part. I haven't worked with CMSs. Yet I have worked with automated systems, and observed them over time. The path of simple to complex is all too easy to follow.

Public, private, and on-premise clouds

The cloud platform is flexible. It's primary degree of flexibility is scalability -- the ability to add (or remove) processing nodes as needed. Yet it has more possibilities. Clouds can be public, private, or on-premise.

Public cloud The cloud services offered by the well-known vendors (Amazon.com, Microsoft, Rackspace). The public cloud consists of virtual machines running on shared hardware. My virtual server may be on the same physical server as your virtual server. (At least today; tomorrow our virtual servers might be hosted on other shared hardware. The cloud is permitted to shift virtual servers to suit its needs.)

Private cloud These are servers and services offered by big vendors (Amazon.com, Microsoft, IBM, Oracle, and more) with dedicated hardware. (Sometimes. Different vendors have different ideas of "private cloud".) The cost is higher, but the private cloud offers more consistent performance and (theoretically) higher security as only your servers are running on the hardware.

On-premise cloud Virtual servers running on hardware that is located in your data center. The selling point is that you have control over physical access to the hardware. (You also pay for the hardware.)

Which configuration is best? The answer, as with many questions about systems, is: "it depends".

Some might think that on-premise clouds are better (even with the higher cost) because you have the most control. That's a debatable point, in today's connected world.

An aspect of the on-premise cloud configuration you may want to consider is scalability. The whole point of the cloud is to get more processors on-line quickly (within minutes) and avoid the long procurement, installation, and configuration processes associated with traditional data centers. On-premise clouds let you do that, provided that you have enough hardware to support the top level of demand. With the public cloud you share the hardware; increasing hardware capacity is the cloud vendors responsibility. With an on-premise cloud, you must plan for the capacity. If you need more hardware, you're back in the procurement, installation, and configuration bureaucracies.

Startups that want to prepare for rapid growth benefit from the public cloud. They can defer paying for servers until they need them. (With an on-premise cloud, you have to buy the hardware to support your servers. Once bought, the hardware is yours.)

Established companies with consistent workloads benefit little from cloud processing. (Unless they are looking to distribute their processing among multiple data centers, and use cloud design for resiliancy.)

Even companies with spiky workloads may want to stay with traditional data centers -- if they can accurately predict their needs. A consistent pattern over the year can be used to plan hardware for servers.

The one group that can benefit from on-premise clouds is large companies with dynamic workloads. By "dynamic", I mean a workload that shifts internally over time. If the on-line sales website needs the bulk of the processing during the day and the accounting systems need the bulk of the processing at night, and the workloads are about the same, then on on-premise cloud makes some sense. The ability to "slosh" computing power from one department to another (or one subsidiary to another) while keeping the total computing capacity (relatively) constant fits well with the on-premise cloud.

I expect that most companies will look for hybrid configurations, blending private and public clouds. The small, focussed, virtual servers for cloud allow for rapid re-deployment to different platforms. A company could run everything on their private cloud when business is slow, and when business (and processing) is heavy shift non-critical tasks to public clouds, keeping the critical items in-house (or "in-cloud").

Such a design requires an evaluation of the workload and the classification of tasks. You have to know which servers can be sent to the public cloud. I have yet to see anyone discussing this aspect of cloud systems -- but I won't be surprised when they do.

Small programs need small languages

The history of programming languages has been one of expansion. Programming languages start small (think BASIC, Pascal, and C) and expand to provide more capabilities to the programmer (think Visual Basic, ObjectPascal, and C++). Programming languages expand because the programs we write expand.

Computer programs have expanded over the years. Books from the early years of programming (the 1970s) classify programs by size, with small programs consisting of hundreds of lines of code, large programs consisting of tens of thousands of lines, and "humongous" programs consisting of hundreds of thousands of lines of code. Today, we may still classify programs by lines of code, but most commercial applications range in size from hundreds of thousands of lines to tens of millions.

The expansionist effect on programs is tied to their single-computer nature. When a single computer must perform the calculations, then the program it runs must do everything.

Cloud computing breaks that paradigm. With cloud computing, the system may be large, but it consists of many computers providing granular services. That design allows for, and encourages, small programs. (Side note: If you're building a cloud system with large programs, you're doing it wrong.)

Cloud computing uses collections of small programs to assemble systems. Since the programs are small, the programming languages can be -- and should be -- small. That means that our strategy of language development, in which we have (mostly) striven to broaden the capabilities of programming languages, is no longer valid. Our new strategy must be to simplify, and probably specialize, our programming languages.

Web services use the Unix way

Web services use a very different mindset than the typical Windows application. Windows applications are large, all-encompassing systems that contain everything they need.

Web services, in contrast, are small fractions of a system. A complete system can be composed of web services, but a web service is not a complete system.

We've seen this pattern before. Not in Windows, nor in PC-DOS or MS-DOS, but in Unix (and now Linux).

"The Art of Unix Programming" by E.S. Raymond covers the topic well. The author describes the philosophy of small, connectable programs. Each program does one thing well, and systems are built from these programs. Anyone who has worked with the Unix (or Linux) command line knows how to connect multiple programs into a larger system.

We don't need to discover the properties of good web services. We don't need to re-invent the techniques for desiging good web services. The properties and techniques already exist, in the command-line philosophy of Unix.

The mobile/cloud revolution has no center

In some ways, the mobile/cloud market is a re-run of the PC revolution. But not completely.

The PC revolution of the 1980s (which saw rise of the IBM PC, PC-DOS, and related technologies) introduced new hardware that was cheaper and easier to use than the previous technologies of mainframes and minicomputers. Today's mobile/cloud revolution shares that aspect, with cloud-based services and mobile devices cheaper than their PC-based counterparts. It's much easier to use a phone or tablet than it is to use a PC -- ask the person who installs software.

The early PC systems, while cheaper and easier to use, were much less capable than the mainframe and minicomputer systems. People ran large corporations on mainframes and small businesses on minicomputers; PCs were barely able to print and handle a few spreadsheets. It was only after PC-compatible networks and network-aware software (Windows 3.1, Microsoft Exchange) that one could consider running a business on PCs. Mobile/cloud shares this attribute, too. Phones and tablets are network-aware, of course, but the whole "mobile and cloud" world is too new, too different, too strange to be used for business. (Except for some hard-core folks who insist on doing it.)

Yet the two revolutions are different. The PC revolution had a definite center: the IBM PC at first, and Windows later. The 1980s saw IBM as the industry leader: IBM PCs were the standard unit for business computing. Plain IBM PCs at first, and then IBM PC XT units, and later IBM PC-compatibles. There were lots of companies offering personal computers that were not IBM-compatible; these offerings (and their companies) were mostly ignored. Everyone wanted "in" on the IBM PC bandwagon: software makers, accessory providers, and eventually clone manufacturers. It was IBM or nothing.

The mobile/cloud revolution has no center, no one vendor or technology. Apple devices are popular but no vendors are attempting to sell clones in the style of PC clones. To some extent, this is due to Apple's nature and their proprietary and closed designs for their devices. (IBM allowed anyone to see the specs for the IBM PC and invited other vendors to build accessories.)

Apple is not the only game in town. Google's Android devices compete handily with the Apple iPhone and iPad. Google also offers cloud services, something Apple does not. (Apple's iCloud product is convenient storage but it is not cloud services. You cannot host an application in it.)

Microsoft is competing in the cloud services area with Azure, and doing well. It has less success with it's Surface tablets and Windows phones.

Other vendors offer cloud services (Amazon.com, IBM, Oracle, SalesForce) and mobile devices (BlackBerry). Today's market sees lots of technologies. It is a far cry from the 1980s "IBM or nothing" mindset, which may show that consumers of IT products and services have matured.

When there is one clear leader, the "safe" purchasing decision is easy: go with the leader. If your project succeeds, no one cares; if your project fails you can claim that even "big company X" couldn't handle the task.

The lack of a clear market leader makes life complicated for those consumers. With multiple vendors offering capable but different products and services, one must have a good understanding of the projects before selecting a vendor. Success is still success, but failure allows others to question your ability.

Multiple competing technologies also means competition at a higher level. In the PC revolution, IBM and Compaq competed on technology, but the basic platform (the PC) was a known quantity. In mobile/cloud, we see new technologies from start-up companies such as containers and new technologies from the established vendors such as cloud management and the Swift programming language.

The world of mobile and cloud has no center, and as such it can move faster than the old PC world. Keep that in mind when building systems and selecting vendors. Be prepared for bumps and turns.

Technology fragmentation means smaller, simpler systems

In the past, IT shops standardized their technologies, often around the vendor deemed the industry leader. In the 1960s and 1970s, that leader was IBM. They offered products for all of your computing needs, from computers to terminals to printers and even punch cards.

In the 1980s and 1990s, it was Microsoft. They offered products for all of your computing needs, from operating systems to compilers to office suites to user management. (Microsoft offered little in hardware, but then hardware was considered a commodity and available from multiple sources.)

Today, things are not so simple. No one vendor that provides products and services for "all of your computing needs". The major vendors are Microsoft, Apple, Amazon.com, Google, and a few others.

Microsoft has a line of offerings, but it is weak in the mobile area. Sales of Microsoft tablets, Microsoft phones, and Windows Mobile are anemic. Anyone who wants to offer services in the mobile market must deal with either Apple or Google (and preferably both, as neither has a clear lead).

Apple has a line of offerings, but is weak in the enterprise area. They offer tools for development of apps to run on their devices but little support for server-side development. Anyone who wants to offer services that use server-side applications must look to Microsoft or Google.

Amazon.com offers cloud services and consumer devices (the Kindle) but is weak on development tools and transaction databases. Google offers cloud services and consumer devices as well, but lacks the enterprise-level administration tools.

Complicating matters is the plethora of open-source tools, many of which are not tied to a specific vendor. The Apache web server, the Perl and Python languages, several NoSQL databases, and development tools are available but not with the blessings (and support) from vendors.

Development teams must now cope with the following:

Browsers: Internet Explorer, Chrome, Firefox, Safari, and possibly Opera
Desktop operating systems: Windows (versions 7, 8, and 10), MacOS X, Linux (Ubuntu, SuSE, and Red Hat)
Platforms: desktop, tablet, phone
Mobile operating systems: iOS, Android, and possibly Blackberry and Windows
Database technologies: SQL and NoSQL
HTTP servers: Apache, NGINX, and IIS
Programming languages: C#, Java, Swift, Python, Ruby, and maybe C++ or C
Cloud platforms: Amazon.com AWS, Microsoft Azure, Google cloud
Cloud paradigms: public cloud, private cloud, or hybrid

I find this an impressive list. You may have some factors of your own to add. (Then the list is even more impressive.)

This fragmentation of technology affects your business. I can think of several areas of concern.

The technology for your systems You have to decide which technologies to use. I suppose you could pick all of them, using one set of technology for one project and another set of technology for another project. That may be useful in the very short term, but may lead to an inconsistent product line. For example, one product may run on Android phones and tablets (only), and another may run on Apple phones and tablets (only).

Talent for that technology Staffing teams is an on-going effort. If your project uses HTML 5, CSS, JavaScript, and Python with a NoSQL database, you will need developers with that set of skills. But developers don't know everything (even though some may claim that they do) and you may find few with that exact set of technology. Are you willing to hire someone without on of your desired skills and let that person learn them?

Mergers and acquisitions Combining systems may be tricky. If you acquire a small firm that uses native Android apps and a C#/.NET server-side system, how do you consolidate that system into your HTML, CSS, JavaScript, Python shop? Or do you maintain two systems with distinct technologies? (Refer to "inconsistent offerings", above.)

There are no simple answers to these questions. Some shops will standardize on a set of technologies, combining offerings from multiple vendors. Some will standardize on a vendor, with the hope of a future industry leader that sets the standard for the market. Many will probably have heated arguments about their selections, and some individuals may leave, staying more loyal to the technology than the employer.

My advice is to keep informed, set standards when necessary, and keep systems small and simple. Position your technology to shift with changes in the industry. (For example, native apps on Apple devices will shift from Objective-C to Swift.) If your systems are large and complicated, redesign them to be smaller and simpler.

Build and maintain systems with the idea that they will change.

They probably will. Sooner than you think.

We need a new UML

The Object Management Group has released a new version of UML. The web site for Dr. Dobb's asks the question: Do You Even Care? It's a proper question.

It's proper because UML, despite a spike of interest in the late 1990s, has failed to move into the mainstream of software development. While the Dr. Dobb's article claims ubiquity ("dozens of UML books published, thousands of articles and blogs posted, and thousands of training classes delivered"), UML is anything but ubiquitous. If anything, UML has been ignored in the latest trends of software: agile development techniques and functional programming. It is designed for large projects and large teams designing the system up front and implementing it according to detailed documents. It is designed for systems built with mutable objects, and functional programming avoids both objects and mutable state.

UML was built to help us design and build large complex systems. It was meant to abstract away details and let us focus on the structure, using a standard notation that could be recognized and understood by all practitioners. We still need those things -- but UML doesn't work for a lot of projects. We need a new UML, one that can work with smaller projects, agile projects, and functional programming languages.

The rise of the simple UI

User interfaces are about to become simpler.

This change is driven by the rise of mobile devices. The UI for mobile apps must be simpler. A cell phone has a small screen and (when needed) a virtual keyboard. The user interacts through the touchscreen, not a keyboard and mouse. Tablets, while larger and often accompanied by a real (small-form) keyboard, also interact through the touchscreen.

For years, PC applications have accumulated features and complexity. Consider the Microsoft Word and Microsoft Excel applications. Each version has introduced new features. The 2007 versions introduced the "ribbon menu", which was an adjustment to the UI to accommodate the increase.

Mobile devices force us to simplify the user interface. Indirectly, they force us to simplify applications. In the desktop world, the application with the most features was (generally) considered the best. In the mobile world, that calculation changes. Instead of selecting an application on the raw number of features, we are selecting applications on simplicity and ease of use.

It is a trend that is ironic, as the early versions of Microsoft Windows were advertised as easy to use (a common adjective was "intuitive"). Yet while "intuitive" and "easy", Windows was never designed to be simple; configuration and administration were always complex. That complexity remained even with networks and Active Directory -- the complexity was centralized but not eliminated.

Apps on mobile don't have to be simple, but simple apps are the better sellers. Simple apps fit better on the small screens. Simple apps fit better into the mobile/cloud processing model. Even games demonstrate this trend (compare "Angry Birds" against the PC games like "Doom" or even "Minesweeper").

The move to simple apps on mobile devices will flow back to web applications and PC applications. The trend of adding features will reverse. This will affect the development of applications and the use of technology in offices. Job requisitions will list user interface (UI) and user experience (UX) skills. Office workflows will become more granular. Large, enterprise systems (like ERP) will mutate into collections of apps and collections of services. This will allow mobile apps, web apps, and PC apps to access the corporate data and perform work.

Sellers of PC applications will have to simplify their current offerings. It is a change that will affect the user interface and the internal organization of their application. Such a change is non-trivial and requires some hard decisions. Some features may be dropped, others may be deferred to a future version. Every feature must be considered and placed in either the mobile client or the cloud back-end, and such decisions must account for many aspects of mobile/cloud design (network accessibility, storage, availability of data on multiple devices, among others).

Best practices are not best forever

Technology changes quickly. And with changes in technology, our views of technology change, and these views affect our decisions on system design. Best practices in one decade may be inefficient in another.

A recent trip to the local car dealer made this apparent. I had brought my car in for routine service, and the mechanic and I reviewed the car's maintenance history. The dealer has a nice, automated system to record all maintenance on vehicles. It has an on-line display and prints nicely-formatted maintenance summaries. A "modern" computer system, probably designed in the 1980s and updated over the years. (I put the word "modern" in quotes because it clearly runs on a networked PC with a back end database, but it does not have tablet or phone apps.)

One aspect of this system is the management of data. After some amount of time (it looks like a few years), maintenance records are removed from the system.

Proper system design once included the task of storage management. A "properly" designed system (one that followed "best practices") would manage data for the users. Data would be retained for a period of time but not forever. One had to erase information, because the total available space was fixed (or additional space was prohibitively expensive) and programming the system to manage space was more effective that asking people to erase the right data at the right time. (People tend to wait until all free storage is used and then binge-erase more data than necessary.)

That was the best practice -- at the time.

Over time, the cost of storage dropped. And over time, our perception of the cost of storage dropped.

Google has a big role in our new perception. With the introduction of GMail, Google gave each account holder a full gigabyte of storage. A full gigabyte! The announcement shocked the industry. Today, it is a poor e-mail service that cannot promise a gigabyte of storage.

Now, Flickr is giving each account holder a full terabyte of storage. A full terabyte! Even I am surprised at the decision. (I also think that it is a good marketing move.)

Let's return to the maintenance tracking system used by the car dealer.

Such quantities of storage vastly surpass the meager storage used by a few maintenance records. Maintenance records each take a few kilobytes of data (it's all text, and only a few pages). A full megabyte of data would hold all maintenance records for several hundred repairs and check-ups. If the auto dealer assigned a full gigabyte to each customer, they could easily hold all maintenance records for the customer, even if the customer brought the car for repairs every month for an extended car-life of twenty years!

Technology has changed. Storage has become inexpensive. Today, it would be a poor practice to design a system that auto-purges records. You spend more on the code and the tests than you save on the reduction in storage costs. You lose older customer data, preventing you from analyzing trends over time.

The new best practices of big data, data science, and analytics, require data. Old data has value, and the value is more than the cost of storage.

Best practices change over time. Be prepared for changes.

"Not invented here" works poorly with cloud services

This week, colleagues were discussing the "track changes" feature of Microsoft Word. They are building an automated system that uses Word at its core, and they were encountering problems with the "track changes" feature.

This problem lead me to think about system design.

Microsoft Word, while it has a COM-based engine and separate UI layer, is a single, all-in-one, solution for word processing. Every function that you need (or that Microsoft thinks you need) is included in the package.

This design has advantages. Once Word is installed, you have access to every feature. All of the features work together. A new version of Word upgrades all of the features -- none are left behind.

Yet this design is a form of "not invented here". Microsoft supplies the user interface, the spell-check engine and dictionary, the "track changes" feature, and everything else. Even when there were other solutions available, Microsoft built their own. (Or bought an existing solution and welded it into Word.)

Word's design is also closed. One cannot, for example, replace Microsoft's spell-checker with another one. Nor can one replace the "track changes" feature with your own version control system. You are stuck with the entire package.

This philosophy worked for desktop PC software. It works poorly with cloud computing.

In cloud computing, every feature in your system is a service. Instead of a monolithic program, a system is a collection of services, each providing some small amount of well-defined processing. Cloud computing needs this design to scale to larger workloads; you can add more servers for the services that see more demand.

With a system built of services, you must decide on the visibility of those services. Are they open to all? Closed to only your processes? Or do you allow a limited set of users (perhaps subscribers) to use them?

Others must make this decision too. The US Postal Service may provide services for address validation, separate and independent from mailing letters. Thus companies like UPS and FedEx may choose to use those services rather than build their own.

Some companies already do this. Twitter provides information via its API. Lots of start-ups provide information and data.

Existing companies and organizations provide data, or will do so in the future. The government agency NOAA may provide weather information. The New York Stock Exchange may provide stock prices and trade information (again, perhaps only to subscribers). Banks may provide loan payment calculations.

You can choose to build a system in the cloud with only your data and services. Or you can choose to use data and services provided by others. Both have advantages (and risks).

But the automatic reflex of "not invented here" has no place in cloud system design. Evaluate your options and weigh the benefits.

Higher-level constructs can be your friends

Lee Brodie, inventor of the Forth language, once said: "I wouldn't write programs in Forth. I would build a new language in Forth, one suitable for the problem at hand. Then I would write the program in that language."

Or something like that.

The idea is a good one. Programming languages are fairly low level, dealing with small-grain concepts like 'int' and 'char'. Building a higher level of abstraction helps you focus on the task at hand, and worry less about details.

We have implemented this tactically with several programming constructs.

First were libraries: blocks of commonly used functions. All modern languages have "the standard libraries", from C to C++ to Java to C# to Python.

Object-oriented programming languages were another step, tactically. They promised the ability to "represent real-world concepts" in programs.

Today we use "domain specific languages". The idea is the same -- tactically.

I keep qualifying my statements with "tactically" because for all of our efforts, we (the programming industry, as a whole) tend to not use them. Not at a strategic level.

We use the common libraries. Any C programmer has used the strxxx() functions, along with the printf() and scanf() family of functions. C++, Java, and C# programmers use the standard-issue libraries and APIs for those languages. We're good at using what is put in front of us.

But very few projects use any of these techniques (libraries, classes, and DSLs) to create higher levels of objects. Most projects use the basic language and the constructs from the supplied framework (MFC, WPF, Struts, etc.) but build very little above these levels.

Instead of following Leo Brodie's advice, projects take the language, libraries, and frameworks and build with those constructs -- and only those constructs. The code of the application -- specifically the business logic -- is built in language-level constructs. There is (often) no effort in building libraries or classes that raise the code to a level closer to business logic.

This low-level design leads to long-term problems. The biggest problem is complexity, in the form of code that manipulates ideas at multiple levels. Code that calculates mortgage interest, for example, includes logic for manipulating arrays of numbers for payment amounts and payment dates. The result is that code is hard to understand: When reading the code, one must mentally jump up and down from one level of abstraction to another.

A second problem is the use of supplied objects for something similar. In Windows MFC programs, many systems used CString objects to hold directory and file names. This is convenient for the initial programmer, but painful for the programmers who follow. A CString object was not a file name, and had operations that made no sense for file names. (The later .NET framework provided much better support for file and path names.) Here, when reading the code, one must constantly remind oneself that the object in view is not used as a normal object of the given type, but as a special case with only certain operations allowed. This imposes work on the reader.

Given these costs of using low-level constructs, why do we avoid higher-level constructs?

I have a few ideas:

Building higher-level constructs is hard: It takes time and effort to build good (that is, useful and enduring) constructs. It is much easier (and faster) to build a program with the supplied objects.

Constructs require maintenance: Once "completed", constructs must be modified as the business changes. (Code built from low-level objects needs to be modified too, but managers and programmers seem more accepting of these changes.)

Obvious ramp-up time: Business-specific high-level constructs are specific to that business, and new hires must learn them. But with programs built with low-level constructs, new hires can be productive immediately, since the system is all "common, standard" code. (Systems have non-obvious ramp-up time, as new hires "learn the business", but managers seem to accept -- or ignore -- that cost.)

Can create politics: Home-grown libraries and frameworks can create political conflicts, driven by ego or overly-aggressive schedules. This is especially possible when the library becomes a separate project, used by other (client) projects. The manager of the library project must work well with the managers of the client projects.

These are not technical problems. These challenges are to the management of the projects. (To some extent, there are technical challenges in the design of the library/class/framework, but these are small compared to the managerial issues.)

I still like Leo Brodie's idea. We can do better than we currently do. We can build systems with better levels of abstraction.

New dimensions in system design

The technology environment is changing. The change is significant, affecting the basic dimensions with which we measure systems.

The center of the old technology world was Windows. Manufacturers built PCs to run Windows. Suppliers built software to run on Windows. Systems were local -- that is, they ran in a single location. Before the internet era, everything lived in your data center. Even with the internet, systems ran in a single data center. (Or possibly two, for redundancy.)

With everything in one data center,  

The age of "Windows as the center of the universe" has passed. Today, we have multiple environments. The simple universe of one technology has been replaced by a universe of multiple galaxies.

Today, systems that are spread across multiple hardware installations. Systems consist of one (or several) front end "user clients", possibly for the iPhone, Android phones, and web browsers. The back end consists of not one but many cooperative services, each handling a small portion of the work. These can include web servers, database servers, queue managers, and content distribution networks.

But the change is larger than that. The set of basic elements is changing. In the old world, systems were built from a database, access, and programs written in a specified language. Those "dimensions" of the application defined its "space" in the data center. Vendors were defined by how well they met the needs of the organization in those dimensions.

In the new world, systems are more complex. Instead of a single database, a system may use several. Instead of a single web server, an application may use multiple, depending on the transaction being processed. We use virtualized processors to host servers, and cloud computing to manage the virtualized servers. We no longer think of a system as "a Java application"; we think of it as "a Java, Javascript, SQL, NoSQL, message queues, and some HTML and CSS" system.

In such a complex world, we design our systems with a new collection of "building blocks", and we look for vendors to provide those building blocks. Those elements of system design are: hardware, software, content, and services. These are the dimensions for system architecture and vendor offerings.
Let's look at the big providers:

Microsoft clearly supplies software: Windows, Office, Visual Studio, and many other packages. They are getting into the hardware game. Microsoft has offered hardware for years, in the form of the Microsoft Mouse, the Microsoft Keyboard, and today with the XBOX, the Kinect, and the Surface. They also offer cloud services and content (music, books, and movies).

Google offers some hardware (the Nexus phones and tablets) but also works with manufacturers. They offer the Chromebook hardware that runs their Chrome browser. They offer cloud services. They have also gotten into the music and video markets, with Google play and YouTube.

Amazon.com offers hardware, but only the the form of the Kindle. They do not offer PCs or phones. They have a rich offering of services with their cloud systems.

Apple offers hardware, software, content, and little in the way of cloud services. Their MacBooks and iPads (and the operating systems) are respected by all. They provide content in the form of music, movies, books, and newspaper subscriptions. Yet their focus is on consumers, not the enterprise. This is clear in their iCloud offerings, which are designed for individuals.

In this light of hardware, software, services, and content, the other "big names" of the tech world are lacking:

Barnes and Noble offers hardware (Nook tablets and e-readers) and the software to run them, but nothing for development or the office. They offer content but not services.

IBM offers hardware and software but not content. They don't sell books or music. They offer cloud services, in addition to their old-school consulting services.

Facebook offers services and content, but not hardware and software. (This is why the rumor of a Facebook phone keeps returning.) Facebook uses cloud computing for their servers but doesn't offer it to customers. They offer other services, such as a platform for games and an authentication service for web site log-ins.

Yahoo offers services and some (limited) content but not hardware or software.

I'm not claiming that a vendor needs all four of these components to be profitable. IBM and Yahoo are doing rather well. (Barnes and Noble not so much, but that is a problem specific to their market.) But the presence (or absence) of these four components is important, and decides how a vendor can assist a client.

The new dimensions of hardware, software, services, and content affect hiring organizations too. Systems will need all of these components (to one degree or another) to satisfy a customer's needs. When looking for solutions from vendors, and when looking to hire, companies will have to weigh the strengths of the vendor (or the candidate) in all of these areas.
The smart, big vendors are offering all services. The smart, small vendors will offer a carefully selected subset and ensure that they can provide quality. The same goes for candidates. The heavyweights will have expertise in all areas, the middleweights light expertise in all and strength in a few, and the lightweights will be capable in one or two.

The task for vendors (and candidates) is to build their skills along these dimensions, and present them to clients.

Self-service does not mean customers are servants

The drive for efficiency leads companies to eliminate employees. Sometimes they do this under the guise of "self-service" machines or kiosks.

For example, banks eliminated tellers by using ATMs.

Now grocery stores are eliminating checkout clerks with self-service checkout kiosks. These are small, unmanned stations at which a customer can scan and bag their purchases without the assistance of a store employee. It is a way for grocery stores to reduce work -- at least from their point of view. In effect, the store has not reduced work but transferred it to the customer. The work is "off the books" as far as the corporate accountants are concerned -- but not to the customers.

Perhaps it is beneficial to review the actions that occur at a grocery store:

• A customer enters the store
• The customer travels through the store and selects items from shelves, placing them in a cart
• The customer brings the items to the checkout counter
• The customer (or sometimes the checkout clerk) removes the items from the cart
• The checkout clerk reviews each item and records the price
• The checkout clerk informs the customer of the total
• The customer pays for the items
• The customer (or sometimes the checkout clerk, or the bagger) puts the items back into the cart
• The customer leaves with the purchased items

There is a lot of "adding to the cart" and "taking out of the cart". More than is necessary, perhaps.

At the manned counter, especially before the days of bar codes and on-line inventory systems, a customer had to take all of their items and let the checkout clerk hold them, one at a time. This was necessary for the clerk to calculate the proper payment amount.

Over time, the checkout process has become more efficient. Instead of manually tabulating the result, a register was used to perform the calculations. Instead of handing items to the clerk one at a time, a moving belt was introduced, allowing one customer to put items in place while the previous customer paid. Bar codes eliminated the need for clerks to hunt for and read a price tag, and eliminated the need for the clerk to key-punch the amount.

But despite all improvements, the general process of "items from shelf to cart", "from cart to clerk", and "from clerk to cart (again)" remain. The self-service checkout kiosks keep these steps; the change is that the customer acts also as the checkout clerk.

Perhaps there is a simpler process. Why should the customer remove the items from the cart only to put them back into the cart (albeit this time in bags)?

The answer to that question is, of course, so that the register can tally the cost of the items. Implied in that answer is the assumption that the checkout kiosk must be the item to tally the items.

But must the kiosk be the tally-er?

Suppose we let the cart perform the tallying. As a customer adds an item to a cart, the cart could record the event, look up the price, and display a running tally for the customer. The cart could even have a slot for payment cards or NFC equipment for cell phone payments.

With such an arrangement, the customer could simply walk around the store, select items, and when finished swipe a credit card and leave the store. There would be no un-pack/re-pack step.

This idea is requires work:

• We need some way for carts to identify that items have been placed inside them. (And not simply nearby, perhaps in an adjacent cart.)
• Carts will also need a way to identify when an item has been removed
• Carts must have some connection (perhaps wi-fi) to the store's point-of-sale control system, to look up prices
• Some items are sold by weight (deli items and some fruits and vegetables) and the cart would have to weigh the item

This idea is not perfect:

• All of these features make carts more expensive
• By constantly displaying the total, "smart carts" may discourage purchases

Yet there are advantages:

• Store gain floor space, as they do not need checkout kiosks
• There are no lines for checkout (not even for the self-service kiosks, which we got rid of in the previous item)
• As a customer selects an item, smart carts can recommend other items (or perhaps offer coupons) in real time

So maybe we can look at self-service in a new light. Instead of pushing the work onto the customer, perhaps we can eliminate the work completely. Banks eliminated tellers by using ATMs, but they eliminated many more positions by using a different technology: credit cards.

Credit cards made it possible for people to purchase without checks or cash. After their introduction, banks saw fewer people withdrawing cash for purchases (fewer people at teller windows) and fewer checks for purchases (fewer checks to be processed).

And the ability to use a credit card to purchase items was something that made the internet and web a useful thing for many people. And drove more business.

I think that the successful technologies will be the ones that:

• Eliminate tasks, or greatly reduce their effort
• Enable people to do new things

The technologies that turn customers into servants? Those, I think, will have a short life.

Pick a cloud... any cloud

Lots of folks have advice for cloud projects. Some folks have offered a traditional bit of advice: "Pick a reliable vendor who will stay in the industry. You want a vendor for a long-term relationship."

Cloud offerings, even in early 2013, are diverse and unsettled. Cloud services and infrastructures are growing and being refined. New vendors are entering the market. (I just read about GE entering the cloud services market.)

Cloud technology, if I may use the phrase, is up in the air. It is changing, as I write this. There is no clear leader in the field. Different vendors offer different types of cloud services, some compatible and some not. The offerings of cloud services remind me of the days before the IBM PC, when many vendors offered different microcomputer systems (Apple, Radio Shack, Commodore, North Star, Sol, etc.).

The problem with picking a vendor that will stay in the field is that no one knows which vendors will stay, or which vendors will keep their technology. One can argue that Amazon.com is the market leader, and one might pick them in the belief that they will keep their lead. Or one could pick Microsoft and their Azure platform, in the belief that Microsoft will endure as a company. These are good guesses, but in the end they are guesses. There is no guarantee that these companies will remain in the cloud services market, or that they will keep their current set of offerings.


Here's my advice:

Become familiar with cloud technologies. You don't have to train all of your staff or convert all of your systems, but develop enough knowledge to evaluate the different platforms and their suitability to your business.

For an established company, develop some small projects with cloud technology. Instead of converting your major systems to cloud, convert some minor ones. (Or develop some new products.) Assign a portion of your staff to these pilot projects with the technology. (Or better yet, a few different technologies.)

For a start-up, the plan is different. Start-ups have no legacy systems, and no risk of offending existing customers. On the other hand, they have very few (possibly one) product. If you're developing your one and only application in the cloud, you want to get it right. My recommendation is to try a few cloud systems, commit to one, and develop with an eye to migrating to another system. Avoid getting locked in to a single vendor.

Actually, avoiding vendor lock-in is a good idea for anyone using cloud services, start-up or established. Building systems this way is difficult and more expensive. It is a hedge against the vendor going out of business (or out of the cloud business). As a hedge, it is an expense that must be evaluated carefully by the managers of the company.

But my big advice is to avoid picking the "winning" cloud services provider. The market is immature and too volatile. No standard has emerged, and any vendor can fail.

Cloud services use cheap, easily configured servers (usually virtualized, but that's not important here) that can be quickly replaced in real-time should any fail at any time. A little bit of that thinking applied to vendors (any can fail at any time) may be a good guide when designing a cloud-based system.