Predix Compared to Other Cloud Platforms—and 14 Tips for PaaS Migration

Learn how Predix differs from IBM Bluemix, AWS Beanstalk, OpenStack, and AWS, as well as what preconditions should be met to move your apps to a PaaS easier.

Platforms for digital transformation

predix-meetup-dallas

Industries are being inevitably disrupted by digital transformation. To survive, organizations should act proactively, rather than simply adapt to changes, as these happen too fast. This idea was elaborated on by Renat Khasanshyn and Elena Travkina of Altoros at the recent IoT meetups in Milwaukee and Dallas.

“It is not the question if a certain industry will get disrupted, the question is just when, and how big the bang will be—either a small one (when you’ll need to figure out what to do with 20% of your workforce) or a big one (when you’ll need to figure out what to do with 90% of your workforce). Because some industries are in that space.” —Renat Khasanshyn, Altoros

Given this fact, large enterprises today don’t have any other choice but to become a software company. For example, if your main business is selling shoes, when employing a new digital strategy you can consider selling fitness experience relying on data and wearable devices. For many industrial companies, the adoption of platforms such as Cloud Foundry, IBM Bluemix, AWS Elastic Beanstalk, or Predix may accelerate digital transformation.

Predix is a platform as a service (PaaS) from GE, built for industrial workloads. Industrial assets connected to Predix Machine produce valuable data enabling predictive maintenance and better efficiency of these assets.

A brief Predix overview

At the meetups, Renat and Elena compared Predix to other cloud platforms and presented 14 portability considerations that can help developers and operators to move their apps to a PaaS like that more smoothly.

 

Predix vs. other PaaS systems

IBM Bluemix

Comparing Bluemix and Predix, Renat noted that both platforms are based on Cloud Foundry and can be deployed on public and private clouds. Both have services for IoT, but the main advantage of GE Predix is that it has access to data from the edge of the network, according to Renat. All the engines, windmills, and everything else that GE manufactures send data using a particular protocol and optimize the rest of the chain using this protocol, making the whole process better, cheaper, and faster.

This end-to-end control gives GE a power over its competitors, as it can influence hardware design or change a protocol overnight, bringing better customer experience and compliance through better integration. GE collects a huge amount of data from its machines and has models to analyze this data for their customers. Industrial IoT is, without doubt, Predix’s cup of tea.

Comparison of Predix and IBM Bluemix

 
AWS Elastic Beanstalk

As Elena outlined, one of the main differences between the two platforms is that the apps in Beanstalk are in virtual machines, whereas apps on Predix are in containers. Thus, Predix apps are faster to scale and deploy, taking seconds instead of minutes.

“Predix is based on Cloud Foundry and (therefore) has all the Cloud Foundry advantages.”
—Elena Travkina, IoT Practice Lead, Altoros

Core deployment architecture with Predix and Cloud Foundry

Renat also explained that every time you push an app to Predix, the platform creates a container with your app. Predix doesn’t host databases, so your app communicates with them through service brokers, which connect an app to all the external services (such as Time Series).

In addition, Predix supports multiple cloud environments, whereas Beanstalk is limited to AWS. Another difference of Predix from Beanstalk is a built-in logging system.

Comparison of Predix with AWS Elastic Beanstalk

 

Predix vs. cloud platforms

OpenStack

Unlike OpenStack and other cloud systems, Predix is a PaaS, which means you don’t have to manage any infrastructure and can focus on creating apps, adding value to your business processes. With OpenStack, you will be responsible for tuning and configuring all the infrastructure, before you can use it for software development and deployment. As Elena noted, Predix can save time: while the timeframe from the start of development to a proof of concept with OpenStack can be 3–4 weeks, with Predix it can be reduced to 2 weeks.

“With Predix, we can focus on building and managing applications and business outcomes, not infrastructure.” —Elena Travkina, Altoros

Comparison of Predix and OpenStack

 
Amazon Web Services

Renat mentioned that, with AWS, you are locked into a certain way of doing things and can’t abstract from the proprietary interfaces of Amazon. AWS uses only its public cloud and doesn’t focus on the industrial IoT, thus doesn’t provide needed protocols and security.

Comparison of Predix and AWS

 

14 recommendations for porting apps

Renat suggested considering 14 portability concerns when developing new apps or migrating existing ones to Predix. These portability considerations are aimed to reach the goals similar to 12 factors for building cloud-native apps. An app architecture built on these principles may ensure easier maintenance, reliability, scalability, and portability across execution environments.

  1. Dependency management. Try to bring down dependencies (to local libraries, for example) to a minimum.
  2. Stateless sessions. In stateless apps, information about a client’s session is not stored on the server, but on a client’s device, which is good for the offline-first approach and eliminates dependency from previous sessions.
  3. Local disk storage. Avoid using local disk storage, as a Predix app works inside containers, and the links to local disk storage simply won’t work.
  4. Configuration variables with environment variables. Configuration files shouldn’t be hardcoded, as these are more difficult to change if it later becomes necessary.
  5. Available ports. Avoid using specialized ports, since Cloud Foundry allows to use only three of them: 80 (HTML), 443 (SSL), and 4443 (TCP). Your application should be adjusted to these Cloud Foundry requirements.
  6. Runtimes and frameworks. Try not to use customized runtimes and frameworks. If you need these, you will have to create your own buildpack—a special interface in Cloud Foundry. So, actually, it’s possible, but more time-consuming than utilizing standard versions.
  7. Background apps (no web interface). Keep in mind Cloud Foundry requirements and containers structure when building these.
  8. The deployment workflow in Predix and Cloud Foundry

  9. Stateless processes. Components of a stateless app can be easily redeployed—in case of failure—as well as scaled out or connected to other apps through APIs. So, all long-lasting states should not be stored within the app, but rather supported by the backing services.
  10. External services. These should be built using the microservices approach instead of a monolithic software/app—otherwise, you will lose scalability. Predix implies high levels of security, so make sure your external services keep up to it.
  11. Separation of concerns. Simply put, you’d better not make a single software unit responsible for many different things at once. When designing an app, decompose the main functionality—so that each smaller feature executes a task independent of other functions.
  12. Hardware dependencies. Abstracting hardware architecture dependencies away from the core functions of the app is vital for app scalability.
  13. Continuous integration (CI). Using CI tools is a best practice, as it gives you stable builds and fast releases. Cloud Foundry allows you to use various CI frameworks, such as Jenkins.
  14. Ignored files. Our recommendation is not to deploy ignored files to Cloud Foundry or Predix.
  15. System libraries. To work with system libraries properly, use temporary objects instead of /tmp folders and local files.

With these 14 things in mind, migration to a cloud platform (including Predix) may be smoother, preserving scalability of apps and enabling easier maintenance.

 

Want details? Watch the videos!

In this session presented in Milwaukee, Renat Khasanshyn of Altoros outlines 14 portability concerns when moving apps to an IoT platform. He also provides an in-depth overview of Predix, its under-the-hood mechanisms, services, and differences from IBM Bluemix, Cloud Foundry, and AWS Elastic Beanstalk. In addition, Renat covers top Predix use cases and integration opportunities with the Predix service catalog for ISVs and SaaS providers.

 

 
Another session on the topic was delivered by Elena Travkina in Dallas. She provided an insight into Predix’s services and under-the-hood mechanisms. Elena also compared the platform to the existing alternatives: Cloud Foundry, IBM Bluemix, and AWS Elastic Beanstalk. Then, she enumerated 14 portability concerns one may face when moving apps to an IoT platform. While talking about the likely scenarios of Predix evolution, Elena highlighted integration opportunities of ISV / SaaS providers, which may be interested in adding their products to the Predix catalog.

 

 
Here are the slides presented by Elena and Renat.

 

Further reading

 

About the experts

renat-khasanshyn
Renat Khasanshyn is CEO at Altoros and Venture Partner at Runa Capital. His primary focus is bringing “software assembly lines” and “data lakes” into organizations through training, deployment, and integration of the solutions offered by the Cloud Foundry ecosystem. Renat is an active member of the Cloud Foundry Foundation Advisory Board and a frequent speaker at Cloud Foundry events. In the past, he has been selected as a finalist for the Emerging Executive of the Year award by the Massachusetts Technology Leadership Council and once won an IBM Business Mashup Challenge.

 

elena-travkina
Elena Travkina is IoT Development Practice Lead at Altoros. She has 10+ years of experience in delivery and support of business critical software applications. Elena worked closely with business owners, providing strategic and organizational leadership for software development. She served in different capacities ranging from a software engineer to an engineering manager. Elena also participated in organizing and supporting the Belarus Ruby User Group.

 


The post is written by Nadia Fedotova and Alex Khizhniak.