Cloud Native Apps with Cloud Foundry

By Al
At the core of the Digital Transformation we find applications. These applications are a new breed of applications that are often referred to as Cloud Native Applications (CNA), Platform 3 apps or simply web apps.

Why is a new type of application required? What's wrong with my good old 2 tier Oracle application?In the age of cloud and web scale services, organizations seek:
  • the ability to scale up and down seamlessly, often to thousands of instances
  • they are required to work with is much larger datasets that often includes non-traditional data types
  • non-disruptive patching
  • the ability to better withstand hardware failures
  • finally there is a desire for simpler and lower cost operations
So what are some characteristics of Cloud Native Applications?
  • They tend to leverage more varied backend options, such as NoSQL databases
  • They are built as a set of microservices that interact with each other in a known manner instead of a monolithic fashion
  • They provide reliability at the software level
  • They use Open Source at all levels
  • They are deployed and operated using Infrastructure as Code techniques
How do CNAs help us meet those requirements? In order to achieve all these, CNAs are architected following  12-factor methodology. You can read more about it in here. If you are in mood of a lighter read you can read here or here.

It is interesting to echo two of the 12 factors to understand how Cloud Foundry help you deliver Cloud Native Application:
  • Dependencies - Explicitly declare and isolate dependencies. We will discuss this with an example in this post.
  • Config - Store configuration details such as credentials or external resources. In the future posts we will see specific examples of how to get your app to work different services (Redis, MongoDB, S3 ...) by reading the necessary information from the environment.
But first, what is Cloud Foundry?

It is an open source, multi cloud application platform as a service (PaaS). It was originally developed by VMware. It was later transitioned to Pivotal when this company was created. It was eventually turned into an Open Source project governed by the Cloud Foundry Foundation. Cloud Foundry based PaaS is offered by most cloud providers and by Pivotal themselves. It can be deployed on-prem with supported versions from Pivotal or deployed as an appliance from DellEMC. In the Pied Piper program we have be using Pivotal Cloud Foundry.

Many customers are concerned with betting on a single cloud provider, as this expose them to outages, unexpected price increases, etc. Given that Cloud Foundry PaaS is so ubiquitous nowadays, by following the 12-factor methodology organizations can essentially create many cloud-independent applications.

But that's enough talking for a day. Let's get our hands dirty. In order to start you will need:
  • Create an free Pivotal Cloud Foundry account
  • Login to your account, give your Organization a name and create a Space to deploy to
  • Install CF CLI
Then open a command prompt or terminal depending on your OS, create a directory and place on it the following 3 text files:
  • app.py - This is the actual Python code
  • Procfile - Here we tell Cloud Foundry that upon starting the instance it must run app.py
  • requirements.txt - This is where we define the "dependencies", one of the 12 factors
import os
from flask import Flask

app = Flask(__name__)

@app.route('/')
def mainmenu():

    return """
    <html>
    <body>
    <center><h1>Hello World!</h1><br/>
    </body>
    </html>"""

if __name__ == "__main__":
 app.run(debug=False,host='0.0.0.0', port=int(os.getenv('PORT', '5000')))

You can get the files or copy their content from this Github repository:
https://github.com/cermegno/CF-hello-world


Then from the terminal run the following to log in to your Cloud Foundry account and select the "space" you created:
cf login -a https://api.run.pivotal.io

It is time for magic! Now simply decide on a name for your application (ex: piperhw) and type:
cf push piperhw

The push process will take about one minute. Open your app in a web browser as follows: "http://piperhw.cfapps.io"


IMPORTANT: The name of your app is how you want your app to be accessed, and it has no bearing with the name of the Python script, "app.py" in this instance. The name you choose must be unique from any other application already running in Cloud Foundry. Look what happens if I try to choose the name "test" for my application:


From here you can decide to scale out your application by spinning up multiple instances:

cf scale piperhw -i 2
cf apps

By default Cloud Foundry assumes that you need the latest version of Python 2 for your script.


If you need a different version (for example a Python 3  version) you can do so with an additional text file called "runtime.txt" and specifying the version of Python you need with a single line of text like this:

python-3.6.1

If you want to go further with web app development look for a Flask tutorial. We developed our own basic one for the Pied Piper program. If you are interested you find it in this Github repo:
https://github.com/cermegno/GeekDay-Lab1

Comments

Post a Comment

Popular posts from this blog

Sending PowerStore alerts via SNMP

By Al
Image
In this previous article we discussed how to leverage PowerStore's powerful API to collect audit logs and send them to a Syslog server . We used Logstash to do that because of its extensive list of plugins Sometimes I come across organizations that still have a requirement to send storage array Alerts to SNMP. As in the Syslog case, ultimately most modern monitoring tools today support collecting information via REST API because that's the way the application world is going, i.e. the cloud native way ... it would be fun to see Prometheus monitoring Kubernetes via SNMP :) However there is still some requirement out there for SNMP traps, so we will explore how to do it. For simplicity we will use the same toolset that we used in the previous article. I encourage you to revisit quickly the article as we did an extensive introduction to Logstash, with practical examples as well as a description of the logs available in PowerStore. I won't cover those aspects in this article I
Read more

Electronic Nose - eNose

By Al
Image
In the previous article I provided details on VeeFarm which was one of the best projects we saw in ANZ Pied Piper 2019 edition and one of the best projects in the history of the program. The program inspired me and others to work together to showcase a great idea and the Pied Piper program itself during our presales conference. An idea I suggested to enhance VeeFarm was an electronic nose that could be used to detect the optimal ripening of the produce to advise the owner that it is the right time to pick it up the produce. This is an idea I had in the backburner for a while but never found the time to work on. Vee gave me the perfect excuse. The electronic nose, or eNose for short, is a custom PCB that hosts a range of gas sensors. For the proof of concept, I used the cheap MQ sensors. These are designed mostly for hobbyists and makers and they barely cost $1 per sensor. As one could expect, tweaking and calibrating these sensors it is even harder than the most expensive counter
Read more

Use Vagrant to deploy to AWS

By Al
Image
In the Pied Piper program we run through a Vagrant tutorial as we found it a great tool to help set up other labs. We are not going to cover Vagrant in detail in this blog as there are plenty of good examples out there. If you are interested in the exercises we did you can visit the repository: https://github.com/cermegno/vagrant-lesson However, something I felt is not sufficiently document and would make a good candidate for a post is how to use Vagrant to deploy to AWS and particularly from Windows. I found a couple of posts that provided good detail but none of them prevented me from running into Windows specific issues. If you are running it from Linux, this article will still help you as I will point out the differences anyway. Install prerequisites Firstly, as the Vagrant documentation states, "providers" other than VirtualBox require a plug in. This is how you install the AWS provider: vagrant plugin install vagrant-aws Deploying to AWS EC2 generally mea
Read more