FIRM BENEFITS - USING CLOUD SOLUTIONS

Monday, June 12, 2017Jenny Assheton-Smith

Cloud computing, very different to hosting, has enormous benefits for businesses. Law firms large and small will stand to benefit the most from this innovative technology.

Many legal practice management solutions are now being offered as "cloud" solutions. Effectively these vendors "cloud offering" is to provide their solutions hosted on a server in a datacenter for each of their clients.

Cloud computing and hosting are similar, in that cloud computing also uses computers hosted in a datacenter, but there is a fundamental difference between hosting and cloud computing.

RYAN'S JOURNEY TO THE CLOUD

To explain the differences and the benefits of using cloud applications, we will travel a journey with Ryan who decided to venture into his own practice.

In setting up his practice, Ryan decided to use the legal practice management system that his previous firm used since he knew the application. This application, an older application was mature and feature rich.

When engaging the salesman of the application, he learned that initially, while he was the only user he could have the application installed on his laptop and the application, although it would take a chunk out of his working capital with its upfront cost, seemed to be a good investment.

This solution worked reasonably well for a time, however, Ryan was not big into accounting, and every week he would have to hand over his laptop to his bookkeeper to update his accounting transactions.

Ryan also became concerned about losing his laptop with all that confidential information on it and was worried that if something did happen to his laptop whether he would be able to restore his data and the application quickly enough to not impact his business.

Over the next year Ryan put these concerns on the back burner and built his practice. Being a great lawyer, Ryan's practice became very busy and he soon had to employ more lawyers and support staff. He called in the application salesman and was quite shocked at how much more capital he had to invest so that all his staff could access the system.

Ryan received a laundry list of items that needed to be purchased and services that needed to be secured.

File Server – Ryan had to try and predict how much his firm would grow in three years and what his peak demand would be on the system to avoid having to upgrade or buy a new file server before the one he purchased came to end of life in that 3 years
Operating System licenses for the server
Additional client licenses for his application
A service agreement with an IT company to set up a firewall and security on his server, to run remote backups for his server and manage updates to the server, and to install and manage remote access for his users
A service agreement with the application provider to install the client version of the application on all his users desktops
Annual license fees for most of the above

What Ryan learned was that the application he had chosen was an older application based on what he found out was older client/server technology that did not use newer web technology.

In discussing his dilemma with a colleague, Ryan learned that he did not have the whole picture of the costs and maintenance of the proposal he was considering. And the laundry list grew, he would need to provide additional funding and consider the cost of

Downtime and the service cost when new releases to the application had to be installed on the server and each of the users desktops
Possible upgrades to the operating system licenses

After some research, Ryan found an application that he learned was web/server technology. This application, aside from having to transfer his history across to the new application, was appealing to Ryan as it cut out some of the service costs that he would incur with his existing application.

Ryan then gave the bad news to his current application salesman who promptly issued him with a revised proposal where a lot of the headache on the IT management side would be removed. This proposal was to provide the application hosted in a datacenter, for which Ryan would pay a monthly fee. He did not even have to buy the equipment; it would be all in the monthly fees.

Faced with not having to outlay a large chunk of capital again, this solution was highly appealing to Ryan.

Update from web/server application sales guy – they could offer the same solution! And the maintenance costs would still be lower because the client application in this solution was a browser, which did not need updating when the server application was updated.

Frustration, obfuscation and bamboozlement

Now Ryan was really frustrated, having to go back and compare again the costs, planning out what his peak usage would be so, that whichever solution he chose would be specified correctly to avoid even more downtime to upgrade the hardware provisioned for his firm in the datacenter, and to figure out which was the most efficient and cost effective solution for him.

Venting his frustration to another colleague again, this colleague asked Ryan whether the web/server application he was considering was a true cloud application. "Well, I guess so" said Ryan, "I mean it must be a cloud application since it's on the internet…"

Unfortunately, Ryan, hopelessly ignorant of technology and just wanting to practice law, and make a decent living at doing so, was being given the real run around.

Let's unpack what Ryan had learned.

Client/Server Applications

He first learned that applications are architected as client/server applications. This means that where there is more than one user that needs to access an application, the main application is installed on a server, and client applications that enable users to access the application on the server as well as being installed on each of the users desktops.

Web/Server Applications

Next he learned that more modern applications are web/server applications. These applications do not need a specific client application on users desktops as they use internet browsers to access the application on a web server.Client-Server

Hosted Applications

Then he learned that both types of application can be implemented in his office (known as on premise) or hosted in a datacenter. Just as he thought he was getting a grip on all this technology, his colleague intimated that there was more to learn.

Cloud-Native Applications

The latest and regarded as the most advanced, here-to-stay technology, cloud-native applications are architected to use cloud computing which, while similar to hosting in a datacenter, is vastly more cost effective and efficient.

While these applications are also web/server applications, they are purpose built (designed, architected and developed) to use cloud technology. Cloud technology provides an array of tools and processes that, when implemented in an applications architecture, eliminates all the waste in maintenance downtime, capital outlay and service cost from users.

To understand the differences, the table below groups non-cloud-native client/server and web/server applications in a hosted environment together as "Traditional Applications" to compare to "Cloud-Native Applications".

TRADITIONAL APPLICATIONS	CLOUD-NATIVE APPLICATIONS
Versioned deployment Software is released in major or minor versions often with months between releases, clients wait for features to be released, missing opportunities and must endure down time when the updates are released. Often these new versions have so many changes that users need additional training to take advantage of the new functionality.	Continuous deployment Updates are continually deployed when ready as the architecture of the solution's code has reduced dependencies, can be tested and then released. Because the increments in the features and functionality are relatively small and bite sized, users find it quick and easy to learn the new stuff and firms don't incur the cost of downtime for training with their users.
Operating system dependent These applications are developed using code that is closely tied to the underlying operating system, hardware and storage. This means that when a new version is released, to install the new version may require an operating system upgrade as well, increasing the cost of implementing the new version and the downtime experienced for the upgrade. Worse, in the event of equipment failure, downtime can be unexpected not planned as in an upgrade.	Operating system independent Developed using code that is independent of underlying infrastructure and use platform services that provide functionality to provision rolling infrastructure in the event of equipment or operating system maintenance or failure. When reallocation of resources occurs in the cloud, it is almost never noticed by users of cloud-native applications. If they did, they would probably blame a bad internet connection, rather than a cloud resource reallocation!
Peak sized capacity Applications need peak size infrastructure provisioned due to the application's architecture not providing for horizontal scaling. So in Ryan's case, he would have to estimate how much his firm would grow in order for the salesman to calculate how much infrastructure, at his peak demand, Ryan's firm would need. These applications can only vertically scale, involving downtime when infrastructure requires upgrading to address peak capacity.	Right sized capacity Infrastructure is provisioned automatically with dynamic allocation or reallocation or resources as required by demand on the application. Ryan would never have to estimate his demands on the underlying infrastructure. Use of cloud infrastructure, when implemented in a cloud-native application, is both scalable and elastic. This means usage can grow and shrink over time (scale), and can stretch (elastic) for peak usage at any point and is collectively referred to as horizontal scaling.
Siloed Development and Operations operate separately, with developers handing over to operations placing the application into production increasing delivery time to end users. An example of how this silo environment impacts would be the planning of an upgrade to either the infrastructure or the application. Ryan's application provider and his firm would need to negotiate time with the operations department of the datacenter when they could have access to install the application update, or for the hardware to be updated by their engineers.	Collaborative Cloud technology provides DevOps, which are a set of mostly automated tools and platforms to provision additional infrastructure or to deploy application enhancements to production. In the instance where the infrastructure or operating systems needs to be updated, the DevOps tools provide rolling infrastructure, moving the application to servers that have already been updated. This provides for seamless rollover of new features and functionality delivery to users, and updated infrastructure.
Manual scaling Provisioning of infrastructure requires manual processes and is slow and complex at scale providing greater margin for errors and downtime. When hardware needs to be upgraded, applications need to be taken down with the underlying infrastructure as they are not built to flip to another server automatically. These applications are tied to a single server and even though a new server can be built before moving the application to the new infrastructure, there will be some downtime while the changeover to the new server is implemented. The margin for error creeps in where users have been alerted to not use the system (very few traditional applications have functionality to instantly lock out all users) and they continue to do so in the window until they are aborted from the server and the backup of the database of the application can become outdated.	Automated scaling Downtime due to human error is eliminated. Consistent rule sets are used across any size deployment. Cloud-native applications are not tied to a single server and operate through load balancers. As more infrastructure is required it is provisioned and the load balancers take care of the rest, redirecting user requests to newly provisioned upgraded infrastructure without any downtime or service degradation to end users who are blissfully unaware of the changes that have taken place.
Slow recovery Hosting datacenters use virtual machine based infrastructure which allows them to provision infrastructure more cost effectively than each tenant owning or renting a full hardware stack. Virtual machines are servers that run within a single physical machine which machine may have several virtual machines running on it. Although this technology is employed in cloud technology, virtual machines are slow to startup and shutdown and already have a high overhead even before applications are deployed. Because of the single server attachment of traditional applications by the nature of their architecture, recovery or transition to upgraded infrastructure, operating systems and/or applications will be slow with sometimes a significant downtime window.	Rapid recovery Cloud-native applications use microservices and containers to span multiple virtual machines in a managed cluster to provide elasticity, scaling and recovery in the event of a failure. This means that startup and shutdown of virtual machines, no matter how slow they may be, or how much overhead they use, does not impact the delivery of cloud-native applications. And always the load balancers are taking care of where the client requests are being serviced. Well-developed and architected cloud-native solutions will always prioritize web requests to provide a fast web server application experience. This is also one of the reasons why good, fast web applications which have been developed as cloud-native applications provide maximum uptime and are reliable and robust, perfect for the pace at which modern businesses work.

TRADITIONAL APPLICATIONS

CLOUD-NATIVE APPLICATIONS

Versioned deployment

Software is released in major or minor versions often with months between releases, clients wait for features to be released, missing opportunities and must endure down time when the updates are released.

Often these new versions have so many changes that users need additional training to take advantage of the new functionality.

Continuous deployment

Updates are continually deployed when ready as the architecture of the solution's code has reduced dependencies, can be tested and then released. Because the increments in the features and functionality are relatively small and bite sized, users find it quick and easy to learn the new stuff and firms don't incur the cost of downtime for training with their users.

Operating system dependent

These applications are developed using code that is closely tied to the underlying operating system, hardware and storage. This means that when a new version is released, to install the new version may require an operating system upgrade as well, increasing the cost of implementing the new version and the downtime experienced for the upgrade. Worse, in the event of equipment failure, downtime can be unexpected not planned as in an upgrade.

Operating system independent

Developed using code that is independent of underlying infrastructure and use platform services that provide functionality to provision rolling infrastructure in the event of equipment or operating system maintenance or failure. When reallocation of resources occurs in the cloud, it is almost never noticed by users of cloud-native applications. If they did, they would probably blame a bad internet connection, rather than a cloud resource reallocation!

Peak sized capacity

Applications need peak size infrastructure provisioned due to the application's architecture not providing for horizontal scaling.

So in Ryan's case, he would have to estimate how much his firm would grow in order for the salesman to calculate how much infrastructure, at his peak demand, Ryan's firm would need.

These applications can only vertically scale, involving downtime when infrastructure requires upgrading to address peak capacity.

Right sized capacity

Infrastructure is provisioned automatically with dynamic allocation or reallocation or resources as required by demand on the application.

Ryan would never have to estimate his demands on the underlying infrastructure. Use of cloud infrastructure, when implemented in a cloud-native application, is both scalable and elastic.

This means usage can grow and shrink over time (scale), and can stretch (elastic) for peak usage at any point and is collectively referred to as horizontal scaling.

Siloed

Development and Operations operate separately, with developers handing over to operations placing the application into production increasing delivery time to end users.

An example of how this silo environment impacts would be the planning of an upgrade to either the infrastructure or the application.

Ryan's application provider and his firm would need to negotiate time with the operations department of the datacenter when they could have access to install the application update, or for the hardware to be updated by their engineers.

Collaborative

Cloud technology provides DevOps, which are a set of mostly automated tools and platforms to provision additional infrastructure or to deploy application enhancements to production.

In the instance where the infrastructure or operating systems needs to be updated, the DevOps tools provide rolling infrastructure, moving the application to servers that have already been updated. This provides for seamless rollover of new features and functionality delivery to users, and updated infrastructure.

Manual scaling

Provisioning of infrastructure requires manual processes and is slow and complex at scale providing greater margin for errors and downtime.

When hardware needs to be upgraded, applications need to be taken down with the underlying infrastructure as they are not built to flip to another server automatically.

These applications are tied to a single server and even though a new server can be built before moving the application to the new infrastructure, there will be some downtime while the changeover to the new server is implemented.

The margin for error creeps in where users have been alerted to not use the system (very few traditional applications have functionality to instantly lock out all users) and they continue to do so in the window until they are aborted from the server and the backup of the database of the application can become outdated.

Automated scaling

Downtime due to human error is eliminated. Consistent rule sets are used across any size deployment.

Cloud-native applications are not tied to a single server and operate through load balancers. As more infrastructure is required it is provisioned and the load balancers take care of the rest, redirecting user requests to newly provisioned upgraded infrastructure without any downtime or service degradation to end users who are blissfully unaware of the changes that have taken place.

Slow recovery

Hosting datacenters use virtual machine based infrastructure which allows them to provision infrastructure more cost effectively than each tenant owning or renting a full hardware stack.

Virtual machines are servers that run within a single physical machine which machine may have several virtual machines running on it.

Although this technology is employed in cloud technology, virtual machines are slow to startup and shutdown and already have a high overhead even before applications are deployed.

Because of the single server attachment of traditional applications by the nature of their architecture, recovery or transition to upgraded infrastructure, operating systems and/or applications will be slow with sometimes a significant downtime window.

Rapid recovery

Cloud-native applications use microservices and containers to span multiple virtual machines in a managed cluster to provide elasticity, scaling and recovery in the event of a failure.

This means that startup and shutdown of virtual machines, no matter how slow they may be, or how much overhead they use, does not impact the delivery of cloud-native applications.

And always the load balancers are taking care of where the client requests are being serviced.

Well-developed and architected cloud-native solutions will always prioritize web requests to provide a fast web server application experience.

This is also one of the reasons why good, fast web applications which have been developed as cloud-native applications provide maximum uptime and are reliable and robust, perfect for the pace at which modern businesses work.

Being Business Tech Savvy

The conclusion to Ryan's story is that while he was frustrated and annoyed with all the time wasted investigating traditional applications, he eventually found a great cloud-native application and is saving money every day, in fact he knows from the insights he gets from his cloud-native app that he's making more money in revenue with a dramatically improved bottom line from his cost savings than he ever could have imagined.

Not having to become a propeller head himself, Ryan became business tech savvy and is delighted that he has

NO upfront capital outlays every couple of years when his equipment gets to end of life – he just needs laptops/tablets or desktops for his users with access to the internet (which they would ordinarily need anyway)
NO upfront and annual software license fees
NO ongoing upgrade costs and maintenance windows, his app is constantly being enhanced as part of his subscription and his data is upgraded for free every time a new deployment that requires it is made
NO need for backups, his app vendor takes care of that in the cloud too
NO operating system compatibility issues – his app is browser based and his users can use Chrome, Firefox, Edge or Safari
NO data size restrictions
NO need for complex disaster recovery planning
NO special hardware requirements

Ryan and his firm enjoy complete security and peace of mind without complex IT setup requirements, gateways and firewalls, and they now focus on practicing law!

"I love the application's clean and efficient screens, rapid response and ease of use. I am amazed at how powerful the application is and how much time it is saving me, freeing me up to bill more hours. I would recommend it to any law firm that is looking for a single, cost-effective system to manage their practice." – Ryan Tucker, Attorney at Law