Welcome!

Machine Learning Authors: Liz McMillan, Zakia Bouachraoui, Roger Strukhoff, Pat Romanski, Carmen Gonzalez

Related Topics: Machine Learning , @CloudExpo, @ThingsExpo, @DevOpsSummit

Machine Learning : Blog Post

Do You Need PaaS for Cloud Microservices? By @IoT2040 | @DevOpsSummit [#DevOps]

Sergey Sverchkov of Altoros Offers His Analysis

Cloud computing adds flexibility to enterprise IT. When companies wish to take advantage of this, they are finding they need to turn to microservices instead of their traditional, monolithic architectures to accommodate frequent change.

Microservices can overcome the challenges presented by frequent change, "by splitting monoliths into multiple independent services, each with its own simple business logic," according to Sergey Sverchkov, a Solutions Architect with Altoros. Doing so leads to another issue: "choosing either PaaS or IaaS for microservices is an open question, " he says.

Sergey recently posted a thoughtful piece on the topic of PaaS vs. IaaS when implementing microservices on the Altoros blog. Altoros provides system integration services for a worldwide client base with the Cloud Foundry PaaS, yet Sverchov's piece takes a balanced view of which approach to take.

His fundamental point is that a DevOps team will be spending a lot of time monkeying around (my phrase, not Sergey's) when companies work straight to the bare infrastructure; taking the PaaS approach. "An automated PaaS is a bigger investment," he writes, "but it can shrink release cycles from weeks to hours and even eliminate some downsides of the microservices model."

In his post, Sergey covers six different areas regarding the implementation of microservices, and the differences between IaaS vs. PaaS in each of these areas, summarized as follows:

  1. One service for one job. With IaaS, "every service is deployed as an (IaaS) instance; DevOps ar responsible for configuring valid communication interfaces." With PaaS, "scalability can be controlled by a developer. Communication endpoints are served by the PaaS."

  1. Using different tools to implement different services. With IaaS, "DevOps needs to configure an application runtime." With PaaS, "an application runtime is automatically deployed in a PaaS container."

  1. Loose coupling. With IaaS, "The DevOps team manages IaaS instances used for service deployment." With PaaS, "containers are isolated elements for application deployment. Container lifecycle is managed by the Paas."

  1. Developer independence. With IaaS, " DevOps may need to create multiple IaaS environments for each of the development groups." Alternatively, with PaaS, development groups can be managed (using Cloud Foundry terminology) as "organizations" and "spaces."

  1. Continuous delivery. With IaaS, "DevOps engineers need to install and configure build-automation tools and integrate them with a project repository." Specifically with Cloud Foundry, "build-automation solutions can be deployed as a regular application."

  2. Integration with external services. With IaaS, "the DevOps team deploys external services. Applications connect (to them) using properties." With PaaS, "a service broker can be used to deploy and publish some external services. Service binding makes it easier to connect an application instance to external services."

In addition to the item about IaaS/PaaS and microservices, Sergey has authored a much longer technical whitepaper on te general topic of microservices vs. monolithic architectures, available through the blog section of the Altoros website.

I heard a lot of talk last year about major public cloud infrastructure providers starting to subsume PaaS into their offerings. Besides the potential for a new era of vendor lock-in, the IaaS vs. PaaS debate also involves significant functionality issues and questions of the skillsets, and more important, efficiency enterprise IT will have as the presence of cloud - public, private, and hybrid - increases within their organizations. Sergey's post adds value to this debate.

Contact Me on Twitter

Follow Cloud Expo on Twitter

More Stories By Roger Strukhoff

Roger Strukhoff (@IoT2040) is Executive Director of the Tau Institute for Global ICT Research, with offices in Illinois and Manila. He is Conference Chair of @CloudExpo & @ThingsExpo, and Editor of SYS-CON Media's CloudComputing BigData & IoT Journals. He holds a BA from Knox College & conducted MBA studies at CSU-East Bay.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
Using serverless computing has a number of obvious benefits over traditional application infrastructure - you pay only for what you use, scale up or down immediately to match supply with demand, and avoid operating any server infrastructure at all. However, implementing maintainable and scalable applications using serverless computing services like AWS Lambda poses a number of challenges. The absence of long-lived, user-managed servers means that states cannot be maintained by the service. Longer function invocation times (referred to as cold starts) become very important to track, because they impact the response time of the service and will impose additional cost. Additionally, the transition to smaller individual components (much like breaking a monolithic application into microservices) results in a simpler deployment model, but makes the system as a whole increasingly complex.
GCP Marketplace is based on a multi-cloud and hybrid-first philosophy, focused on giving Google Cloud partners and enterprise customers flexibility without lock-in. It also helps customers innovate by easily adopting new technologies from ISV partners, such as commercial Kubernetes applications, and allows companies to oversee the full lifecycle of a solution, from discovery through management.
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reduction in cost and increase in speed. Sometimes in order to reduce complexity teams compromise features or change requirements
Using serverless computing has a number of obvious benefits over traditional application infrastructure - you pay only for what you use, scale up or down immediately to match supply with demand, and avoid operating any server infrastructure at all. However, implementing maintainable and scalable applications using serverless computing services like AWS Lambda poses a number of challenges. The absence of long-lived, user-managed servers means that states cannot be maintained by the service. Longer function invocation times (referred to as cold starts) become very important to track, because they impact the response time of the service and will impose additional cost. Additionally, the transition to smaller individual components (much like breaking a monolithic application into microservices) results in a simpler deployment model, but makes the system as a whole increasingly complex.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throughout enterprises of all sizes.