Taking Stock of Web Services (2001)

Written exactly 5 years before Amazon announced Amazon Web Services (AWS) with EC2.?Still it would be 2012 before AWS went mainstream!

Any time you make bold predictions about an industry, it is fun to look back much later and see how you fared. The following are excerpts from my original article (August 2001). Link at the end.

"The size of the upcoming web services boom has simply not been appreciated. Though one can agree that it is big, how big can it be? This is something that will last very many years as the de facto practice, but will also take many years to get to a stage where it becomes fully viable. The difficulties are many, and so are the opportunities.

For one, the concepts are not yet well understood by companies, developers, or analysts. Therefore there is currently little information available on how web services will be created, deployed, managed, and used in the future, outside of the abstract and confused notions thrown at everyone by marketing hype and varied press and journal reports.

It is indeed amusing to see the hyped and established view of developing web services with some technologies and tools like SOAP and application servers. In fact all one hears about are SOAP, WSDL, UDDI, Java ONE, and similar technologies and vendors’ application server offerings.

As far as tools and technologies go, these represent an extremely primitive stage, comparable to a cave man using clumsy flint stones for his tasks. The complexity and required toolsets for engineering, deploying and managing web services go far beyond the capabilities of these simple offerings. It is na?ve to think that providing an XML based interface through SOAP or some technology on an application server magically creates a web service.

Start with the customer. A good portion of the complexity of managing the enterprise’s software is now to be offloaded to the web services infrastructure. This in itself is a big challenge, considering the range of options various enterprises are used to or need to have. Who are the users? How is access controlled? How is a security policy enforced? Where is the data stored and how is it backed up? What happens on an upgrade? How much of usage has taken place? Who is responsible when something goes wrong? How does one find the source of a problem? And numerous other concerns.

Now trace back to the web services provider. There has to be infrastructure and then the service software. The server clusters will be so numerous as to literally dwarf the past dot-com infrastructure build up. Managing such extra large server networks will naturally require new sets of intelligent switching and routing devices and software. Technologies allowing server virtualization and dynamic application instantiation will be needed. Application partitioning and data synchronization between multiple servers of a web service will be a key problem to solve. Software and devices to meet quality-of-service expectations will become a very important issue. Monitoring and billing (in various customer user choosable modes) bring in a whole load of additional software complexity.

Now consider the software provider. For the engineering team, a major challenge lies in mastering distributed computing. This will be distributed computing on a scale never seen before. One dimension is multiple customer (tenant) support. Another dimension is the numerous servers on which the software should run, co-operate and synchronize data. A software design to handle availability, security, performance, data storage, monitoring, upgrades, bug fixes - all these become much more critical and difficult than ever. Initially companies would attempt to simply replicate installations per customer and thus accelerate time to market, but this stage would soon be superceded by technologies or rework that promises to save costs substantially ("now known as cloud native services").

The concerns of data security are secondary. The question under consideration is whether an enterprise is willing to have its data exposed to a web service, and stored and manipulated outside its premises. This is simply a teething problem, and arises from some amount of ignorance about what technology can accomplish. One, they can choose to trust a web service, just like one trusts a certificate authority like VeriSign with a statement of someone’s identity; a bank with one’s money, or an NDA holding partner with one’s technical and business plans. This would eventually require vetting practices to be enforced on the security policies of many web services. In any case, as web services become further rooted, legislation will take over and define acceptable practices for the industry.?

Secondly, they can choose to deploy web services in their private networks, with limited access to “public” web services. This would be a corporate security policy, until the concept matures further and legislation settles most fears. For some enterprises, the concept of storing data in a “strong hold” or trusted hands would actually be appealing, considering their own overheads in managing data security. Would a Fort Knox for guarding data be valuable?

Third, the benefits and rewards of a pay-per-use model, instant updates, instant feature additions and low maintenance costs will be of great interest to enterprises, encouraging their technocrats and IT managers to lobby greatly towards changing their own corporate policies towards web services. If instant coffee is a huge success, then consider how “instant” software will impact IT departments. The statement is really blown out of proportion, but it is a perfect example of hype.?

Fourth, many would be forced into the web services paradigm. As competition sets in, product vendors will be forced to create web service versions of their offerings. Then the snowball really starts rolling. And like the good queen told Alice, one will have to keep running to stand still.

Finally, the IT industry has no choice. There is little else in the foreseeable future that carries the potential of a big wave comparable to the dot-com rise. And without this kind of boom, the industry will go bust. This is a boom that can be engineered, since the software manufacturers hold the key. And if it can be engineered, it will be, given the circumstances, and regardless of any merits of the web services paradigm."

https://web.archive.org/web/20011019181405/https://www.cswl.com/whiteppr/tech/webservices.html