Welcome!

Machine Learning Authors: Pat Romanski, Yeshim Deniz, Liz McMillan, Elizabeth White, Zakia Bouachraoui

Blog Feed Post

Why Application Modernization is Necessary When You Move to the Cloud?

FutureFor decades we have been developing applications that are tightly coupled and bound to the underlying infrastructure. With the introduction of the cloud though this legacy architectures prove not only to be inefficient but also a major obstacle for you to compete successfully in the new competitive landscape.

 

Let's look at couple of reasons why application modernization is a requirement if you want to leverage cloud technologies, independent of whether those are home grown, private or public.

 

The Problem With Tightly Coupled Applications

Majority of the applications are developed with some user interaction layer, business logic and backend storage. When those are tightly coupled together your only option to scale the application is to add more hardware to the machine that currently runs this application, approach also known as vertical scaling. However there are few problems that arise:

  • Adding more CPU power and memory to the machine has certain limits that are imposed by the hardware architecture. You can invest in more advanced hardware but this increases even more your infrastructure costs (high-end hardware costs several times more than the commodity hardware used in cloud data-centers).
  • The performance of your application is determined by the slowest component in it. Thus even if the UI is super fast and is able to handle large amount of users but the business logic is slow and cannot handle the load you will be limited to the load the business logic can handle. Because the UI and the business logic are tied together you will not be able to scale just the business logic in order to handle more users. This leads to inefficient resource utilization and again higher infrastructure costs.
  • Tightly coupled applications do not normally have clearly separated tiers with defined interfaces and changes in one part of the application may have undesired impacts in another. Tasks like fixing, updating and extending it become a maintenance nightmare. The budget for supporting and maintaining such applications grows each year.

 

Here is how those things get solved in a cloud architected applications:

  • Adding CPU power and memory is trivial - it is just a matter of adding a new instance of the application (or just part of it as you can see in the next bullet point). Cloud enabled applications scale out by adding more instances of the application or the application components that work in parallel (also known as horizontal scaling).
  • The performance of the application is not anymore determined by its slowest component. Because the components of the application are clearly separated you can scale out just parts of the application (i.e. the business logic in the previous example) to match the load that the UI can handle. You have much more flexibility and granular control over the way your application scales.
  • Because the components of the application are clearly separated, changes in one component do not impact another as long as the interfaces are kept in tact. Tasks like testing fixes, updating components, improving the performance of particular tier and any other maintenance and support becomes much easier.

 

The Problem With Local Resources

Another common problem with legacy applications are the dependencies on local resources. Few examples are:

  • Dependencies on locally installed software or libraries. Such dependencies can be specialized server software, local queue implementations, client libraries used for special rendering etc. Lot of the times this software comes with additional licensing costs.
  • Reliance on the local file system. Application logging is a typical example but you can also think of other things like loading data from local files, storing data locally etc. Server failure results in data loss, which in some cases may not be acceptable.
  • Sticky sessions and storing session information locally. Every web application relies on user sessions and each web framework offers a way to manage those on the server side. However if the server fails the session is lost, which impacts the user experience.

The biggest problem with local resources is the assumption that those will be available throughout the lifetime of the application. But even the most reliable hardware can fail and when this happens everything that is stored locally will be lost. The price you will pay for lost data will significantly exceed even the most expensive hardware.

 

Cloud enabled applications solve those problems as follows:

  • Workloads that require specialized software can be deployed on a infrastructure pool that has the software preinstalled. Thus adding more customers will not require new licenses for the software.
  • Critical data as well as logs is stored in a central storage local that is regularly backed up and can even be geo-replicated. The chances of data loss in the cloud are significantly lower.
  • Sessions are stored either in a shared storage or in distributed cache and accessible from each instance of the application. Thus failure in one application instance does not impact the user experience because the next request is routed to another instance.

 

The Problem With Configurations

The last one I would like to touch on is the problem with configuration. Near all applications suffer from the  configurations problem but in legacy applications this is particularly amplified. The whole problem starts with the need to have one configuration that mangoes all components or at least the front-end and the business logic. Then over time this configuration grows and grows together with the new functionality added to the application.

 

But this is not the only issue with legacy applications configurations. The bigger issue is the settings that rely on the underlying infrastructure. This was OK when you were in control of the infrastructure and on which server the application is deployed however this approach results in increased configuration sprawl when the application needs to be moved between environments.

 

When you design your application for the cloud though you are forced to abstract the configuration from the underlying infrastructure and things like hard coded local paths, reliance on local environment variables or machine configurations have no place in your configuration files. Thus you make changes in your configuration only when new functionality is added and not when you move your code between environments (as in development, test, production)

 

Even if you are not considering immediate migration of your applications to the cloud is worth evaluating your application portfolio and estimating the effort to make it cloud-ready. It is of benefit not only for your cloud efforts but as a general strategy for the future.

Read the original blog entry...

More Stories By Toddy Mladenov

Toddy Mladenov has more than 15 years experience in software development and technology consulting at companies like Microsoft, SAP and 3Com. Currently he is a CTO of Agitare Technologies, Inc. - a boutique consulting company that specializes in Cloud Computing and Big Data Solutions. Before Agitare Tech Toddy spent few years with PaaS startup Apprenda and more than six years working on Microsft's cloud computing platform Windows Azure, Windows Client and MSN/Windows Live. During his career at Microsoft he managed different aspects of the software development process for Windows Azure and Windows Services. He also evangelized Microsoft cloud services among open source communities like PHP and Java. In the past he developed enterprise software for German's software giant SAP and several startups in Europe, and managed the technical sales for 3Com in the Balkan region.

With his broad industry experience, international background and end-user point of view Toddy has an unique approach towards technology. He believes that technology should be develop to improve people's lives and is eager to share his knowledge in topics like cloud computing, mobile and web development.

CloudEXPO Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-centric compute for the most data-intensive applications. Hyperconverged systems already in place can be revitalized with vendor-agnostic, PCIe-deployed, disaggregated approach to composable, maximizing the value of previous investments.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by sharing information within the building and with outside city infrastructure via real time shared cloud capabilities.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.