devopsy.kinsta.cloud

Author: Aaron Mulgrew

  • Moving Legacy Applications to the Cloud

    Moving Legacy Applications to the Cloud

    Even in 2021, many companies still run business-critical, legacy applications on-premises, just as they have for the last 20 to 30 years.  The midrange server hardware, and their unique architecture, on which many of these applications run is both their biggest drawback and biggest advantage; the benefits of being able to vertically scale a platform were measured against the drawbacks of the necessary custom hardware. Migrating the workloads running on these types of systems to the cloud, which can potentially offer huge benefits, presents some unique challenges – here are four strategies for doing this, with pros and cons for each.

    Option 1: Lift and Shift

    The “lift and shift” option means you’re simply representing the on-premises network within a cloud service provider. This is the easiest and quickest option.

    Until recently, this was not an option for most legacy applications. This was because the main hyperscale clouds did not offer dedicated infrastructure as-a-service (IaaS) implementations for several common data center operating systems. The process required purchasing a vast amount of dedicated hardware to offer as-a-service to customers, and it wasn’t clear if the demand warranted that cash outlay.

    Recently, however, it’s clear that the only way for organizations can leave behind the data center is by moving business-critical applications to the cloud. There are now hyperscale cloud providers that offer lift and shift options for even the most demanding workloads.

    Despite these benefits, it’s important that a lift and shift approach is carefully planned before executing. Even a couple of seconds of downtime in traditional application workloads can cost businesses thousands of dollars. Finally, organizations should understand that they won’t be using the cloud to its full potential simply by recreating their on-premises environment.

     Option 2: Rewriting or Refactoring

    Refactoring a traditional application into a cloud native application has been the de facto migration option for many years. It provides greater long-term cost savings than other options, because previously underprovisioned data center resources can now be consumed on-demand in the native FaaS offerings of hyperscale cloud providers. The compute capacity is nearly limitless, and only scales as resources are being used.

    However, refactoring to cloud native services does have major risks, such as high short-term costs. Refactoring an existing business-critical application is typically much more complex than a simple lift and shift. Also, an application that has been part of the core business stack will have likely accrued many dependencies and interfaces with other systems and added modules that must be accounted for.

    Another consideration is that legacy interfaces must appear identical to other systems post-migration, otherwise you must expand the scope — including other systems in the migration project that originally weren’t planned. Many of the hyperscale cloud providers do not support legacy interfaces in their cloud native services. Scope creep can become a real issue in this scenario, and your organization could lose sight of the migration timeline.

    An enterprise service bus (ESB) is one potential solution to the problem of legacy interfaces. An ESB is typically deployed as a “bus” between various business applications, ensuring that all those interfaces use a common interface. The ESB handles the network, transport, routing and delivery of messages and content. However, ESBs add yet another layer of complexity, increasing the risk of failure for the overall refactoring project.

    Option 3: Dynamic Lift and Shift (Reshape)

    Reshaping an application to the cloud typically lies somewhere between the lift and shift and the refactoring strategies. It’s similar to lift and shift, but usually involves some minor modification to the application to take advantage of native tools within the cloud infrastructure. An example is adding automated launch and tear down of development and test environments.

    One of the main advantages of a reshaping is that it is cost-effective. An organization will see significant cost savings over a simple lift and shift, for example, by only having to pay for the hours that the development and testing machines are powered up and running.

    It also means that the development teams are free to experiment with refactoring certain applications without a hard deadline (such as a data center exit.) Finally, a dynamic lift and shift strategy allows development teams to leverage cloud native functionality, such as infrastructure as code, to automate traditional workloads without retraining on a whole new development stack.

    Option 4: Drop and Replace with COTS

    Another option is to replace your custom application for one that is commercial off the shelf (COTS). For example, replacing a custom-built customer relationship management (CRM) system with a vendor’s product.

    This is not feasible for some organizations because of their business environment constraints, but it is recommended when possible. COTS products (that are typically SaaS) usually have a repository for various connectors to different legacy applications; however, this is largely dependent on the size and maturity of the COTS product.

    It’s important to note that one of the largest risks of considering a COTS application is the skills within the organization. If the current development team’s skillset lies with custom, traditional applications, they will need extra time to retrain and develop the extensions to integrate the COTS product with their existing environment.

    Migrating any application to the cloud is a large undertaking. There will always be risks when moving existing on-premises applications to the cloud, but in general, the overall positive impact of moving legacy applications far outweigh any risks, regardless of the approach you decide to take.

  • Securing Internet-Facing Portals

    Securing Internet-Facing Portals

    Against the backdrop of the current pandemic, barely a day goes by without another portal or web application being launched to help citizens and customers interact with governments and corporations. Bringing these applications to market quickly, and ensuring they can’t compromise the security of the organization, requires DevOps to embrace news techniques and technologies. So, how best can DevOps ensure these applications don’t become a backdoor for the bad guys?

    Additional Defensive Techniques

    In the OWASP Top Ten list of vulnerabilities in Web Applications, ensuring uploaded documents and images are threat-free doesn’t factor. Yet, these can be the Achilles Heel of any internet-facing portal or application. 

    The primary vehicle for smuggling malware into an organization is via documents and images. These are routinely embedded with malware, some basic, some extremely sophisticated, targeting the user or employee who eventually uploads the document. Alternatively, the concealed malware can attack the portal itself, for example, via a malformed document.

    This malware is sufficiently new and well-concealed that it repeatedly evades detection-based cyber defences and even modern AI technologies. Ensuring that what arrives via the portal is threat-free means finding additional defensive techniques that increase the security without slowing down the application. 

    Best Practice

    The UK’s NCSC has published a set of essential guidelines for anyone charged with the security of an application that must accept documents and images from the internet. In the NCSC “Pattern: For Safely Importing Data,” the organization describes a set of best practice guidelines for accepting documents from untrusted sources and recommends an approach called document transformation to ensure imported documents are threat-free. 

    Transformation is a mechanism whereby untrusted documents and images have the essential business information extracted from them. The originals are then discarded–along with any embedded threats. The business information is then verified and brand-new documents are then created and formatted to match the originals.

    Securing internet-facing portals - Figure 1_transformation engine
    Figure 1: Transformation engine.

    Once documents have been through the transformation engine they are completely safe and can be used without any further security measures.

    “Baked-in” Security Controls

    For the AppSec manager, transformation is a great approach to promote across DevOps teams. It can be accessed via cloud APIs and it adds an additional layer of security–conformant with security best practices–that helps ensure web applications and portals don’t become a backdoor for malware infiltration. 

    Securing internet-facing portals - Fig 2 python
    Figure 2: Uploading a Document via an API.

    Developers need a choice of transformation APIs, depending on the nature of the particular application. For example, some applications will require a simple upload/download API to transform a file, while other applications will need APIs capable of handling more complex tasks, such as event-driven workflows or moving files between different storage buckets.

    Securing internet-facing portals - Fig 3 AWS flow
    Figure 3: AWS Flow Using S3 API.

    Head Start

    The demand for web applications to accept uploaded documents into portals is only going to increase, and with it the risk of potential for compromise from concealed malware. The good news is that any DevSecOps professional building a web application or portal that must accept documents and images from the internet, already has a head start when it comes to building securely if they are using a serverless architecture.

    From a security perspective, the alternative to serverless architectures, machine images in the cloud, have the associated risk that if, for example, malware succeeds in compromising the machine, it remains compromised thereafter. With a serverless, cloud native architecture, there is no residual machine and, therefore, little residual risk.

    Another key point in favor of building on a serverless cloud-native computing model is that it devolves the responsibility of patching to the service provider. It is widely understood that unpatched systems are one of the main causes of cybersecurity breaches. Serverless architectures enable the developer to shift operational responsibilities and routine security tasks, such as patching, maintenance and upgrades, to their service provider. 

    The current pandemic has turbo-charged the demand for internet-facing portals and with it the risk of malware infiltration via uploaded documents and images. For developers, that means finding new defensive techniques like transformation that can be quickly and easily baked into the code to ensure uploads are threat-free.