Life and Death of an application - Part 1: the Birth

Publié le 13 Décembre 2016

The whole applications lifecycle is currently going through massive changes. From creating applications to launching applications, running new applications to transforming existing applications, there's now so many ways to do it, so many choices.... that the hardest part is to understand the benefits & risks of each roads in front of us.

I like to think of this as a "good" problem. It's better having many choices than none.

A common theme among all these new roads is that they all allow to be faster. Faster to develop, faster to deploy.. and also faster to fail.

Looking few years back, applications were much more static than today. They would be developed through rigid methodologies to attain a high degree of completeness as soon as possible. A reason for this was that the agility level was very poor: once deployed, it was hard to make any changes. The development framework had a very low level of abstraction (aka it was very very technical and complicated) and the infrastructure were... well... complicated so you would not risk too many moves there.

Present time: Agile methodology, Development Framework with much higher level of abstraction (aka much simpler to work with), "Software is eating the world" fever all over the place.... In short: much more fun!

It's easier to develop applications, it's easier to deploy, it's easier to run it.... but there are huge problems on the way. The biggest one being "How do I pick up the right road to answer all the Dev needs and all the Ops needs + (saw that one coming isn't it?) the DevOps needs.

As an Ops Guy...

... I haven't touched Development for, well, 15 years (Aargh!). Since my student life really.... So as the DevOps skills seemed so interesting I thought I would give a try of the Dev side for curiosity/challenges sake. Also, I wanted to leave the (beautiful) plumbing of the Datacenter, get to the main deck and, hopefully, be amazed. Well, I have not been disappointed.

As there are now so many roads to Build & Run an application, I also wanted to completely understand the different layers (Code to Infra) to avoid being blocked on my journey to test these different roads.

Finally, one of the important accelerators for development today is the many API's available on Internet for free and delivering outstanding value. I wanted to assess how difficult it was to leverage them.

With all this in mind, I started brainstorming on the kind of app that:

A/ I could achieve given my (low) Dev skills

B/ something that would be at least a little useful.

Therefore, I decided to create a "Time Traffic Overview" app, aka "Tito". This app will analyse the commuting time one do everyday and will show the amount of time spend in traffic.

I took this direction because traffic is a huge problem of our modern age. Everybody get annoyed by traffic , especially during commuting. If you're not, well, you're a lucky one :)

So here we go, let me introduce Tito.

I wanted Tito to do 5 things:

1/ Take the commuting information from someone (home address, home leaving hour, work address, work leaving hour

2/ Ask Google Directions API how long the trip would be for each days of the week

3/ Create stats out of this (per day, per week, per life, per year, per life) => Scary stats!

4/ Display all this through a nice interface with a map of the trip

5/ Put information in a Database.

Also, it's a web app, not a mobile app (easier to demo it).

Here are few screenshots of the application Tito:

Front page

Main Form

Results page

So, I have fulfilled my initial goals. It took me few days to get there but I didn't really find any showstopper.

There are still many things to do to improve Tito but it was not my goal to have something perfect. My goal was to attain a certain functional level.

So overall, the lessons I learned of this little "hackaton" of my own is how powerful are the API's available across the internet. It really open a breadth of possibilities! Imagine the amount of work that would have been needed to do Tito before Google made it's APIs available? It would have been a major project with a multi millions dollar costs.

Now, well... much faster and easier!

Few Dev information

I chose PHP to build my app since it's a simple and very mature language with a strong ecosystem of modules/functions and a vast community (which help a lot for learning and troubleshooting).

I also chose Boostrap from Twitter for pretty much the same reasons.

There's a little javascript in my code but (and that's another finding) I mostly took them from other peoples so don't ask me too much about it. There's a ton of things available so... no need to reinvent the wheel.

For learning the basics, I simply used W3schools. It's all free and very well done.

Regarding the google Directions API call: that was dead easy. The documentation is excellent and you basically just do a HTTP request with few variable in your URL.

https://maps.googleapis.com/maps/api/directions/json?origin=<origin>&destination=<destination>&departure_time=<epoch date>&traffic_model=best_guess&key=<key>

The request result is returned under a typical format such as JSON that PHP will (almost) instantly consume.

I naturally had to invest some time to understand the developer tools.

I used Netbean as an Development Environment (IDE), Git for source management, sourcetree for visualization, Xampp to setup a mini server environment on my Windows and advices from family, friends and colleagues.

For those who want to check how Tito is built, you can find the sources here: https://github.com/vmeoc/Tito

Again, no magic here. It's very simple code.

Hummm.... Something missing here...

I haven't talked about 2 things which, as Ops, I care very much: the app architecture & where this application will run.

Tito architecture is made of an Apache server hosting the PHP Code. Apache needed to be configured correctly to properly handle PHP and pass the backend IP to the applicaton.

The data management is done with MySQL on a separate server. They both have different security level but need to see each other whatever the network configuration is. Obviously, the web server needs to know the IP address of the DB server.

Tito architecture

Where are we going to run Tito?

To answer this we need to look at the many roads available for Tito to take... each with their own benefits and risks.

We just saw the birth of "baby" Tito, in the coming articles we'll see how it walks and runs through these different roads.

To give you a glimpse, I will deploy Tito in a SDDC following a common operating model (VM based), new operating model (container based) and... well, we'll see.

I'll try to automate as much as possible of the Build, Run and update lifecycle events for each one of these models.

Obviously, I will update my blog with my results and thoughts.

Let me know if you have questions and feel free to share!