January 29, 2018
Today’s stakeholders know that delays due to complex Information Technology (IT) processes are no longer acceptable—agility and the delivery of predictable outcomes can mean the difference between success in the marketplace and being displaced by competitors. This shift has led to significant changes in many aspects of the software development lifecycle—most notably, the transition from monolithic architectures to microservice architecture-based applications. As a result, Platform as a Service (PaaS) solutions have become a popular choice because they:
Re-architecting complex monolithic applications using a microservice architecture (MSA) is not a trivial task. The additional challenges of maximizing utilization of infrastructure investments, creating a robust self-service platform for developers, and meeting existing service level agreements (SLA) require serious consideration. However, the idea of provisioning virtual machines and using configuration management platforms to create runtime farms to manage these MSA workloads is neither sustainable nor inexpensive.
This reality leads teams to evaluate PaaS platforms to host and orchestrate the MSA workloads. However, many teams quickly find that they lack proper knowledge of market trends and an understanding of the competing platforms’ strengths and shortcomings to successfully perform an evaluation. This limits a team’s ability to identify a PaaS platform that aligns with their technology and business roadmaps.
This white paper will help decision makers navigate a PaaS evaluation. Outlined below are the 10 questions to ask your PaaS provider when evaluating their platform.
Re-architecting monolithic applications can be challenging for organizations, which adds additional burdens for the staff and increases the chance of failure. For example, the process often involves updating code that was developed a long time ago and and that tends to have poorly documented library and services dependencies. However, many of these monolithic applications provide critical functionality that many other solutions depend on, and they should not be ignored as part of an application modernization effort.
Levvel recommends choosing a PaaS platform that supports and aligns with your organization’s technology roadmap. Comparing a PaaS platform to a technology roadmap often provides teams with an opportunity to ascertain a platform’s strengths and weaknesses, and is therefore an important mile marker in a PaaS platform assessment.
Though some PaaS providers highlight their support for .NET workloads, an overwhelming majority of community resources, such as blogs, articles, and general technical discussions, are about runtimes that do not involve the .Net technology platform. This presents a challenge when teams have to containerize both .Net and non-.Net applications. One suggestion is to initially consider containerizing a traditional non-.Net workload, allowing team members to fully understand the PaaS platform before considering a .Net dependent workload. Many teams may also find containerizing a database as a perfectly legitimate exercise. However, it is very important to fully understand the challenges around database containers and persistent storage before such workloads are considered.
Regardless of the company’s current state and goals during evaluation (efforts to modernize traditional applications, the technology stack in use, or the type of workloads being considered), competing vendors should always provide a thorough demonstration of a transformation effort using candidate applications that closely resemble your technology timeline and roadmap. Seeing such a demonstration of the platform’s capabilities will provide valuable insight into its fit and function, as well as its alignment with your priorities.
Although calculating the true cost of ownership (TCO) should not be a major hurdle for organizations evaluating a PaaS solution, it can still be challenging to properly measure. This is because the TCO is not limited to the acquisition price alone — it also includes the additional costs of purchasing the necessary infrastructure, installing and maintaining the platform, and hiring and retaining a team capable of performing the necessary tasks.
When collecting quotes from vendors, take into consideration all the costs and related factors before deciding, including:
Introducing a new solution in most mature IT environments can be challenging. Anything as comprehensive as a PaaS platform usually requires a significant effort from many teams to implement, including operations and security.
Integrating existing IT solutions with the newly-acquired PaaS platform can be equally daunting; this task brings unique considerations, some of which are listed below.
The need for a strong community should not be trivialized; it is the backbone of your team’s day-to-day experiences until the team achieves a certain level of comfort and mastery of the platform. A robust and growing community can also be a great source from which to hire new talent.
Once the company has selected a PaaS platform, the process of installing and operationalizing the platform can present developers, support, and security teams with a potentially daunting learning curve. Teams often find these initial stages challenging because they can lead to more questions than answers, and often involve time-sensitive problems. Even if the product’s support team is excellent, their lengthy response times and resolution methods may not be able to adequately address the numerous and frequent technical questions the company has. Many of these PaaS platforms also lack accreditation opportunities for users, which results in the need for on-premise training sessions.
All of these issues can lead many teams to rely on the larger community to address the day-to-day technical challenges. Developers, testers, operations, and security team members also benefit greatly from good articles, blogs, and videos on topics relevant to their area of expertise, especially when the content is updated to reflect changing product characteristics. These additional resources provide a good framework to help team members adapt to the new PaaS platform.
Though it is difficult to quantify the benefits of communities, the assistance they can offer significantly improves the team’s ability to learn and troubleshoot platform-related issues during the initial stages. It is important to take these challenges into consideration when evaluating PaaS platforms, and to engage with vendors to understand how they can assist your team as they operationalize the new platform.
If the answer to this question is yes, it is not necessarily a good thing. This is because the first widely-accepted PaaS platform was announced just over 6 years ago—quite recently, when compared to relational databases that have been around for almost 4 decades. However, the pace of change in these newer platforms is far more rapid when compared to most mature proprietary platforms. As a result, it is difficult to predict how these platforms will alter the IT landscape in 5 to 7 years.
Hence, being tied to a PaaS platform can be problematic, especially if that vendor fails to keep up with market trends over time. This leads to a situation where the platform’s dwindling fortunes begin to negatively impact the team’s ability to execute. Aligning with broad market trends is a necessity, ensuring that teams continue moving where the market is headed. PaaS platforms, unlike other mature products, require team members to constantly experiment with emerging technology trends and determine ways in which those technologies can be ingested by ongoing PaaS-based projects.
The Docker and Kubernetes platforms have emerged as the industry standards. In fact, all major PaaS vendors have aligned with these two technology platforms in some manner. However, it is important to note that some PaaS platforms continue to support competing technologies to accomplish the same objectives. This can be confusing for teams undertaking these transformations for the first time.
Here are some high-level pointers to consider when evaluating PaaS platforms:
Different teams, when confronted with similar technical issues, tend to solve them in different ways using a wide range of tools and processes, resulting in diverse IT environments that are held together with myriad processes and systems. Teams have to navigate these complex IT environments while installing and configuring PaaS platforms. The mature processes already in place to address separation of duties, security monitoring, support team runbooks, and account revalidation processes must all be reworked or adjusted to accommodate the new platform. In addition to these activities, simply ensuring that the new processes are well-documented and audited requires a team that is highly informed about the consequences of their decisions. This will prevent unfortunate realizations well into the process that the platform does not support a critical functionality.
To help prevent such situations, it is beneficial to bring development, test, operations, security, and compliance process owners into the evaluation process in the early stages. This allows stakeholders to assess the platforms in consideration and provide critical feedback on the platform’s strengths and weaknesses from different perspectives. Though stakeholders often have a comprehensive list of topics to address, the majority tend to focus on the following areas:
Why should you care about how the market interest for the PaaS platform is changing? Teams sometimes tend to focus on aligning their requirements with a PaaS platform’s features, ignoring the lack of clarity in a product’s roadmap and the vendor’s attempts to align with emerging market trends. Downplaying the importance of this area creates a risk of jeopardizing a critical initiative.
It is important to evaluate vendors’ alignment between their product roadmaps and current market trends. As stated above, the Docker and Kubernetes platforms have gained significant market penetration, and are now considered the industry standard in container and orchestrations technologies. Understanding how these emerging technologies are being integrated into the PaaS platform requires careful consideration.
Though vendors have a vested interest in ensuring the success of their PaaS solutions, the impact when the market shifts away from a particular PaaS platform can be an obstacle for clients who have significant investments in that platform. This shift presents a dilemma for clients, who must balance continuing investments on projects that use the PaaS platform while evaluating alternate strategies to ensure critical long-term deliveries are met.
PaaS platforms are maturing at an incredible pace, experiencing feature churn, while certain contributing technologies are experiencing some of the highest adoption rates the industry has ever seen.
For this reason, a full-fledged Docker and Kubernetes implementation is recommended, not only to align with current market-leading technologies, but to also benefit from the rich feature sets these emerging platforms offer. The growing popularity of these technologies also ensures that users will have the option to move workloads to competing platforms that support these same technologies without compromising a great deal of the functionality.
Implementation with these technologies also benefits teams in their attempts to hire and retain talent, since technologists consider their work experience using Docker and Kubernetes as critical to their long-term career aspirations.
Developers can often find sample code and other resources on the internet. Inserting such code into a product or service without it being scanned for originality or known security vulnerabilities could create significant liabilities. Though teams have started performing code scans in earnest, PaaS platforms introduce a twist in the runtime environment and therefore create an additional area that must be monitored and managed.
Since most teams package their application code to run as a container, scanning the container’s Union File System’s layers for known security vulnerabilities is a critical activity, and it must be included as an automatically-performed step. Developers usually develop the initial image on their laptops and store it the reference image repository. Some PaaS platforms now include software components that allow clients to scan and sign these base images, thereby providing developers with a reliable starting point to begin packaging their application code base, rather than an arbitrary image source downloaded from the internet.
The presence of these automated scans also provides security experts with a reliable audit trail, indicating what was included in those images before they were run as containers in a protected environment, such as production. Educating developers and the larger team about the benefits of integrating the security scan into the product’s lifecycle ensures that IT professionals do not have to manage additional compliance activities before the workloads are deployed in production, thereby encouraging good development activities within the developer community.
Levvel suggests that clients discuss the option of security scans with PaaS platform vendors to ensure that the runtimes and any additional supporting layers in the containers are both compliant and secure.
When working with workloads in a container platform, it may or may not be possible to control the exact location of a workload. Unlike with virtual machines, containers are meant to occupy a significantly smaller footprint and can be scheduled to run on any node in the cluster by the PaaS platform’s scheduler. Also, with the advent of MSA-based applications, it is often possible to quickly identify potential bottlenecks and scale out only those components that are experiencing capacity issues, rather than provisioning additional instances of the entire application.
These two scenarios present the development, security, and operations team members with a unique challenge—how to aggregate the system, security, and application logs in the PaaS platform. It is also important to restrict access, so that only authorized team members have access to relevant logs.
Some PaaS platforms currently offer an out-of-the-box aggregated logging feature that is based on popular platforms in this space, while others provide adequate documentation to install and integrate an aggregated logging solution. The importance of this feature should not be minimized, as most troubleshooting activities performed by the developer, tester, or system administrators heavily depend on it.
When evaluating PaaS platforms, determine what log aggregation features are available by default. If your team already uses a popular logging aggregation solution, include in the evaluation the effort to integrate the existing log aggregation solution with the new PaaS platform.
These questions and their corresponding discussions are intended to assist teams in their efforts to evaluate and select a PaaS platform that suits their needs. If you wish to talk about any of the topics covered in this document in more detail, please contact Levvel at email@example.com.
DevOps Capability Lead
Srinivas "CJ" Coimbatore has over two decades of experience in diverse disciplines such as sales, marketing, software development, architecture and delivery, and has worked with teams in all of the major geographies. He is an effective change agent and is very interested in collaborating with teams that are involved in transforming their process through DevOps. In his spare time, he follows Formula 1 racing teams, rides his motorcycle, and—along with his friends—helps raise money for children with health challenges and for the Pediatric Brain Tumor Foundation, Make-a-Wish Foundation, and Angels Among Us. He hopes to eventually spend more time teaching math and science to children.
At the end of lunch with a mentee, I used the items on our table to express the fundamental concepts of Kubernetes. Sometime after explaining the purpose of the Kubernetes scheduler, she asked a question I spent the next several weeks thinking about.
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.