Introduction: Moving to the Right Cloud, the Right Way

An Enterprise Cloud Story

A large Canadian financial services organization decided to migrate one of its commercial banking applications to the cloud. Moving would save them over one hundred thousand dollars a month in licensing and management fees, while enabling them to introduce new service features faster. Greater agility and scalability for the future made cloud an easy decision for both IT and the line of business to support.

Everything went well during the six-month development cycle and subsequent pilot. Twenty-five clients joined the beta program and feedback on the application enhancements – new banking services – was positive.

Returning more than a million dollars per year back into the bottom line while being first to market with new offerings for business banking customers made this a win for both the line of business and the IT application developers. High fives all around.

The migration and retirement plan began in parallel. Porting more than 50,000 SMB clients would span 6-8 weeks meaning the existing application could be sun-setted quickly.

At one hundred clients, the new cloud app worked great. At one hundred and one, it fell to its knees. Clients could not log on, could not conduct business. The onboarding process was halted. The bank app-dev team scrambled to fix the problem.

Trouble-shooting was not a simple task. The code was complex. It took several weeks, several experts and hundreds of thousands of dollars before the problem could be isolated and resolved.

A memory leak was the ultimate culprit, but lessons learned included the following:

• Artificial timelines set by the business and not challenged by project management;
• A flawed project plan that had siloed teams working independently – emulating a waterfall, rather than an agile, approach;
• A mix of in-house and outsourced developers who lacked expertise or training in the areas they were working in;
• An architecture designed for a traditional legacy model was being replicated in the cloud, without taking cloud economics and best practice into account;

Ultimately, a lack of planning, lack of training and lack of understanding the differences between developing in legacy and developing in-cloud became an expensive corporate lesson. The legacy application was maintained much longer than planned for and this organization’s go-to-market advantage was lost.

Cloud has transformed the way we develop new software applications and modernize legacy applications. When it goes well, it delivers efficiencies, streamlines operations and enables any size of organization to react quickly to market pressures. We believe that it is not a matter of “if” but “when” your organization is moving application development to the cloud. This thinking is supported by many of the leading research organizations including IDC.

Avoid the Fire-Drill

At Optimus we are seeing more and more of our clients take advantage of cloud – in particular applications once thought impossible to move to the cloud – due to scale, complexity or simply because of their mission-critical nature – are now being migrated successfully.

Typically we see clients take one of two approaches when beginning a cloud migration project:

1. Detailed Migration Plan: Clients have decided to move a specific set of applications to the cloud and want help creating a plan and development life-cycle. They engage with us upfront to help including risk assessment, skills training and knowledge transfer, application development and testing, project life-cycle and management as well as help identifying areas of streamlining or efficiencies for business transformation. For example, one of our clients has a software solution for restaurants. They are moving their solution to Azure for scalability, flexibility and the ability to modernize their complete application on both the front end and back end. Our approach has helped them mitigate risk while proving anticipated value as each phase is completed.
2. Mid-Migration Troubleshooting: Clients are in the midst of executing an application development cloud migration strategy and have run into problems that they had not planned for – they bring us in to trouble-shoot and get back on track. One of our clients, a large engineering consulting firm, migrated some of their application to Azure without understanding or taking advantage of Azure services. As a result, they were not able to achieve their anticipated ROI. Our role in this project was to help them retrofit their application so that they could benefit from Azure services.

Obviously our preference is to engage with clients in the first scenario. It means a thoughtful approach where we are able to identify the right architecture and point out the most common design patterns for today’s cloud. There are fewer surprises and we are typically delivering to wins identified at key milestones along the way. 

Scenario two is the “fire-drill” approach and while we are always happy to step in and help at any point, we prefer when our clients can avoid having to press the panic button during a major application development project.

In summary, both scenarios will work. The important part to remember as you transition:

1. Cloud is inevitable. Having evaluated and made a decision to move puts you ahead of many others.
2. Help is available. Every plan has the potential to run into obstacles. Optimus has experience, trained resources and the ability to quickly bring Microsoft into any project if needed.

Which Cloud is Best?

One question we are often asked is “which cloud is best”. As a Gold Partner for Microsoft we have our bias, but our bias is based on research, experience and facts.

We see Azure is an ideal cloud platform for the enterprise. And while Azure (and other cloud platforms) are always evolving, at the time of this writing, the following is true. Let’s take a look at some specific reasons we like Azure over AWS for application development for the enterprise.

In parallel, we believe that Google cloud is simply not robust enough for organizations who rely on Microsoft technology as part of their enterprise suite. Here is list of what we have found to be missing: 

Google cloud does not have mappings for Microsoft/Azure:

• Automation
• Batch
• VM Extensions
• File Storage
• Back Up
• StorSimple
• Site Recovery
• SQL Database Migration Wizard
• Data Catalog
• Bot Service
• Search
• Logic Apps
• Dev/Test Labs
• Xamarin Apps
• Application Gateway Web Application Firewall
• Active Directory
• Active Directory B2C
• Azure Active Directory Domain Services
• BizTalk Services
• Intune
• Power Apps
• Dynamics 365
• Azure Stack
• Government Cloud

Summary

In summary, moving your enterprise applications to the cloud will deliver many benefits in terms of speed-to-market, hyper-scalability and reduced infrastructure costs. Planning and preparing for it, as well as engaging the right people to help you move to the right cloud platform will dramatically reduce your risk. If you can reduce your risk, you have a much better likelihood of achieving the outcomes you and your company defined at the onset of your project.

Chapter One: The Landscape for Cloud Application Development

Gartner has predicted that global spending on enterprise application software will grow to more than $201 billion by 2019. The spending drivers will be modernization, functional expansion and digital transformation projects.

This prediction was driven by Gartner research which further identified the following key trends:

• 45% of survey respondents stated that application modernization of installed on-premises core enterprise software is a top 5 priority;
• 41% of respondents added extending capabilities of core enterprise applications as a top 5 priority;
• More than 50% of new software implementations are moving away from traditional on premises licensing and to consumption-based models such as SaaS, hosted licensing, subscriptions and open source;
• Competing successfully in the digital economy is driving application modernization and re-engineering across the entire supply chain;
• By 2020 75% of application purchases will be “build” not “buy” as organizations demand software that is “differentiated, innovative and non-standard”;
• By 2020 more than 75% of organizations will deploy advanced analytics as part of a platform to improve business decision-making.

 Today’s Cloud Drivers

Companies are clearly making the decision to move to the cloud. We are seeing the following trends in cloud application development:

Driver #1 –Storage Issues / Hardware Failures

The cloud decision is often driven by an immediate need for infrastructure. Either the client has constant storage issues or is experiencing compute or hardware failures. Typically at this point the client will say “enough – we need to make a change – we can’t afford to keep going the way we are going”.

The budget requirements to keep pace with the demands of the business is a big driver for moving to the cloud. More storage or more compute is expensive. Licensing renewals along with hardware refreshes add up, making it a logical point to pause and consider other options.

Companies immediately assume that they will need to move a large portion, if not all, of their data center into the cloud. This is a traditional IT perspective. “I need to increase my storage and add compute, it is time for a data centre refresh.” The conversation is around data centre moves, not around application development but it is a traditional conversation that IT is comfortable having.

Driver #2 – Line of Business Has an Urgent Need

The second trigger driving cloud conversations is when the business is coming to IT with a project they need to do. Similar to our example in the opening – a commercial banking application that needed modernization – the business may want to purchase a new application or refresh a legacy app to offer more for customers, meet mobility needs, drive better data insights or simply run faster.

In these cases, the business is typically looking for a fast time to market and don’t want to wait for the traditional length of time it might take to acquire servers, set up development and test-dev sites or even absorb the capital expenditure necessary for new infrastructure. From this perspective, the business wants to “move now” and is looking at the cloud and possibly to get going.

Driver #3 – Internet of Things

The Internet of Things is transforming industries and how companies can leap ahead of their competition. Examples include:

• manufacturers who can predict when a component is going to break and schedule maintenance without bringing a production line down, saving hundreds of thousands of dollars; 
• retail products helping shoppers decide in a store what to purchase and why;
• resources companies managing vehicles in remote regions, reducing accidents and roll-overs by sensing speed or dangerous driving and then better educating drivers.

According to Jim Tully, vice president and distinguished analyst at Gartner, enterprises will build and adapt their IoT implementations to include a combination of five key architectural components – things, gateways, mobile devices, the cloud and the enterprise.

With cloud as one of the five key components for an IoT architecture, enabling application development in the cloud will ensure your organization is IoT ready.

Chapter Two: Technology Evolution and the Benefits of Developing Applications in the Cloud

New technologies designed to enhance cloud application development are adding to the value of application development modernization. 

Are You Using Containers?

Containers are becoming more and more popular in today’s application development architecture. Docker is the most well-known. It began as an open-source project and helps to automate the deployment of applications within containers, but there are also new container options coming into market. We believe we will see more and more organizations adopt containers as a standard for cloud app dev.

One of the benefits of using containers is that it provides standards around dividing applications and placing them on various physical and virtual machines. This flexibility means the ability to have more control over workload management and system fault-tolerance. In short, better resiliency, better performance and better scalability.

Replacing Monolithic Applications with Microservices

Becoming an agile organization, offering your company the ability to compete and revolutionize in your industry is next to impossible if you are operating monolithic applications inside of a monolithic architecture. Multiple dependences, test/dev processes and deployment constraints (a monolith needs to be deployed in its entirety) will hamper your ability to react to market demands or to quickly be proactive.

To counter this, much of the new application development is taking place as a microservice. A microservice is an architecture type that essentially means building many small services that can act and exist independently, operating instead with connectors that enable them to communicate and operate.

The benefits are obvious. Developers can quickly update and make changes to each microservice without having impact on an entire operation. In the case of any challenges or performance issues, roll-backs are swift and easy to accomplish. Testing is also a much faster and more contained process that does not impact the rest of the application.

Two Benefits of Application Modernization with Cloud

Agility through PaaS (Platform as a Service)

PaaS is an offering that makes your Agile app dev team even more agile. Even when you follow an Agile development methodology, you still have that process in the background where you need to start procuring your servers and you need to set them up and you need to work with IT to get everything up and running.

If you take advantage of a PaaS platform, specifically for those services, then your ramp-up time for your project or your wait time before you can actually deploy your application is dramatically reduced. For many organizations, it can be anywhere from three to five months before hardware is in the racks, connected and accessible which is a big hit on a project.

Azure PaaS has emulators, which makes it easier because your development PC is able to run on your code in exactly the same environment as it would run on Azure. That is because the emulators are really the emulators that run in an Azure production environment. If you develop something locally, then it essentially guarantees that it will run in the cloud as well. This saves tremendous time and makes your team more efficient because now you can isolate the pieces that you’re working on versus trying to debug or diagnose something that is running in a dev environment where there’s a whole bunch of other components running as well. 

Rightsizing Your Environment

One of the challenges in a traditional on premises data centre is getting the sizing right. If you make a mistake, it’s an expensive mistake. When you size for the cloud and make a mistake, the worst that will happen is that for one month your usage bill has increased, but then you can fix it. Basically you can quickly right size at any time. 

Another challenge is peak loads. In a traditional environment you need to plan your hardware for the maximum load, which is often only used during your peak business periods such as Christmas, tax season, end of month, etc. Many services in a data centre will idle around 1% to 4% of CPU usage. The memory is also often barely used but it has been purchased because the vendor has identified a reference architecture for a particular application based on peak performance. Much of the time, your server is not doing anything and that time is simply time wasted.

With Azure you can select a utilization number that supports daily spikes or movement throughout the day, and then rely on your scaling mechanism for daily or weekly peak times where you can add more service to cover the loads. Through dashboards you can monitor your CPU and memory utilization. As it grows, you can scale up to the next server type, making optimum use of your budget and ensuring the environment is always optimized.

 

Chapter Three: Wouter van Eck’s Do’s & Don’ts

Earlier this year Optimus and Microsoft co-presented at a workshop on how to build, migrate and modernize enterprise applications on Microsoft Azure. The following “Do’s and Don’ts” were presented by Wouter van Eck. We believe they are great tips and should be shared here.

DO:  KISS – Keep It Stupidly Simple

The number of problems increases in relation to the complexity of the solution.

• Reduces the time it takes to add new business functionality.
• Reduces the amount of staff needed to develop the solution,
• Reduces maintenance and support effort required.

DON’T:  Apply On-Premises Architecture Behaviour to Cloud Solutions 

The same old approaches don’t work.

• An application doesn’t become scalable, or more stable because you add more servers to the cluster.
• The cloud is inherently more secure, why would you add extra firewalls and security measures if what you need is covered with the use of Network Security Groups (NSG)?
• So much is different, you need to understand how it can be done more efficiently?
• Cloud is evolving – are you keeping up with best practices?

DO: Establish a Cloud Focused (Enterprise) Architecture Vision

Now that you have successfully moved to the cloud, what are your next set of goals?

• Who is responsible for billing and subscription?
• Who is the owner of a subscription?
• How do you procure Azure?
• Who is responsible for consumption?
• How do you monitor consumption?

DO: Choose SaaS, PaaS, IaaS

When looking for a solution, aim for the least amount of responsibility.

• Software as a Service (Office 365)
• Software as a Service with Customization Options (DocuSign)
• Platform as a Service (greenfield, app migration, extension)
• Infrastructure as a Service (last resort, non-cloud ready, legacy or other off-the-shelf apps or systems (SAP)

DO: Establish Cloud Application Best Practices and Architectural Guidelines

Designing for Services is Different than Designing Services

• KISS
• SaaS, PaaS, IaaS Order of Preference
• Continuous Integration / Continuous Deployment
• Agile