In this post, former banking technology architect and current CTO, Patrick Senti, allows us to pick his brain and learn about his experiences with Cloud Foundry and Python/Django.
As background, Senti is an award-winning architect and programmer who is also certified in machine learning. He brings over 20 years of software experience from working on high profile projects at companies like IBM, SAS, and Credit Suisse.
Recently Senti founded shrebo and is currently CTO. Much like Uber, AirBnB, and Zipcar, his company uses cloud platforms to create new ways of sharing resources. shrebo recently won an innovation award from Swiss Federal Railways (who is also a customer) and provides an entire web-services-based SaaS platform—a set of APIs for application developers to build with. Shrebo is the cloud platform for the sharing economy—allowing you to build your own AirBnB or Lyft on shrebo.
The functionality includes search, booking, scheduling, provisioning, payment, and social functionality endpoints surrounding the entire process of sharing resources. With their services, third parties can cost effectively and quickly create sharing applications in mobile, social, local and other contexts to help automate logistics, optimize machinery, increase asset and fleet utilization, and run services for sharing any type of resource like cars, bikes, or parking spaces.
In three short sentences, what defined your needs for a platform like Cloud Foundry?
- Architecting a start-up with a big vision means we needed stability at the ground level.
- We need developers to focus on solving problems and coding instead of technical details.
- While stacks like Amazon were interesting, we needed to be higher up the stack to make service distribution easier.
If you could summarize, what would you say the outcomes have been so far?
This PaaS platform reduces risk and creates a lot of efficiency and effectiveness. Cloud Foundry is a real blast of an experience as a developer. We essentially package the application along with the services manifest and press a button. Everything else is done by the platform. This type of thing used to take days or weeks. Now, it takes minutes.
OK, let’s cover some background. How did you, as an entrepreneur, decide to start this company?
Well, it was really three ideas that came together.
A few years back, I shared a sailboat with other people. It was always difficult to manage the logistics because smartphones were not as common. However, the idea of making the process easier…that stuck with me. I thought, “It would be really useful to have a sharing service for any private resource.”
Two, it’s easy to see how more and more resources are shared between people across companies. If you work at the same company, everyone is on a shared calendar; so, it’s not needed. When people come together across companies, like in a start-up environment or if you share some large asset like trains, you need a better way to share. It seemed like a good idea to have an API-based platform to help build solutions like this.
Lastly, I have done a lot with analytics. I realized there could be process improvement and optimization if people and companies could successfully share information and results. For example, we cooperate with Swiss Federal Railways, who awarded us a winner for innovation as a start-up, and they operate tons of trains and cars each day. The trains are very overused in many city areas. When they are full, commuters don’t know where to sit. In fact, this is a sharable resource. So, my “aha” moment here was about connecting people via a smartphone app—we could allow them to see and chose travel based on load and occupancy. They could make a conscious decision to board a certain train. We could really help improve this if we use predictive analytics. So, we do that too—this is much like managing meeting rooms but on a really large scale.
Could you tell us more about shrebo as a business and how Pivotal and Cloud Foundry fit?
In a nutshell, companies use our stuff to build their own end-user sharing applications.
We are a platform software services for any sharing solution. If you are familiar with car sharing, like a renting process or a smartphone app for scheduling a car like Zipcar or Uber in the U.S., our platform supports all the functionality you would need to build such an app through a set of developer APIs. The shrebo platform allows companies of any size to more easily and cost effectively develop their own sharing applications and online services and mix them with other mobile, social, and local apps.
In our initial architecture process, we evaluated several PaaS providers. Ultimately, we chose App Fog, who is now owned by CenturyLink. They run Cloud Foundry with Python, Java, Node.js, PHP, and Ruby. Our technology framework allows us to elastically provision services through App Fog’s services API. Also, Pivotal provides us with Redis as a data structure service and RabbitMQ as a message broker service.
How will your customer experience be improved through our technologies?
Well, our app is not directly visible through some user interface for end users, it is more of a white label solution. However, we provide app and data services that enable others to provide end-user applications. So, those companies can rely on our API to meet SLAs cost effectively. Eventually, they need their apps to perform or users will go somewhere else. If we fail, so do they.
In the context of us powering other technologies, we use Cloud Foundry and AppFog to provision services much faster, at a lower cost, and with greater scale as real-time demand shifts. This PaaS is certainly more cost effective than Amazon, and it’s less complex and risky than traditional hosting providers who make us build the stack by ourselves. It’s also very automated. All of these things allow us to deliver code, deploy updates, and fix issues on our platform quickly.
Do you have any examples where Cloud Foundry’s Elastic Runtime Service delivered something unexpected?
Yes, absolutely. At one point in time, the AppFog infrastructure needed an upgrade. They had some planned downtime and planned to make changes to one data center at a time across Singapore, Ireland, and the U.S. With Cloud Foundry, we had zero down time even though they did. As they were bringing down a data center to make updates, we set up new instances on the fly and shifted workloads. As they moved around the world, we automatically migrated across data centers. We didn’t have any downtime even though they did! Before Cloud Foundry, this was really not possible. We could increase and decrease instances on the fly. Quite amazing.
How does Cloud Foundry compare to other platforms you have worked with?
Provisioning is so different. So, I spent a lot of time in the financial services industry—for about 10 years. We primarily worked with traditional hosting platforms. You get a Linux machine, then you do an install. Along the process, a group of experts all touch it before it is ready to deploy code. Cloud Foundry it totally different.
Like I said before, Cloud Foundry is a real blast of an experience as a developer. This type of thing used to take days or weeks. Now, it takes minutes. As a CTO, this is the experience every developer has been looking for over the past 10 years. We get the power of scripting—an event can trigger just about anything we need.
What other overarching Cloud Foundry capabilities are top of mind?
Flexibility and agility are top of the list. I see extensibility as a major benefit too. The whole architecture is built with open source contributions in mind. Adding new stacks is encouraged.
How does Cloud Foundry and AppFog support your stack?
Cloud Foundry is the PaaS and AppFog integrates and operates the PaaS and IaaS. They also provide a Django/Python stack on Cloud Foundry. We didn’t have to do anything to get this set up. It was provided when we turned on our account. This is the way development should work!
Could you tell us a bit about the other services you use on Cloud Foundry?
We use Redis and RabbitMQ—these are both very powerful services for data structure and messaging middleware, and we have two main use cases. We use MySQL for persistence, also provisioned and managed by Cloud Foundry.
First, we provide elements of a web app and APIs as a service to the outside world. The runtime is a traditional Python process intended for short-lived, synchronous workloads. Second, there are many asynchronous processes that trigger over time. For example, the website generates a lot of events. If someone is booking a resource, confirming a booking, or cancels, these are all events. Workflow workloads run asynchronously in the background and do various things like send an SMS or email. There is a separation of concerns here between the two types of workloads, short-lived web requests, and longer-lived background tasks, and we use RabbitMQ to decouple these sub-systems, and it is used on both sides.
Our RabbitMQ uses Redis as an in-memory data store to transport the messages between the two areas—the web APIs and the messaging, which is based on Celery as well. In addition, we use Redis as a distributed log instance—as soon as a reservation is made, we want to ensure no one else can grab the resource. Since we have four or five instances on the web API side, we run into a distributed lock problem. Redis solves this problem for us. So, RabbitMQ is the broker, Redis powers the state of notification events, and it also acts as a data store to log transaction events—for all events and messages across the two workloads.
The workflows, events, and messages store data in an analytics warehouse. At this point, we are using Apache Hadoop®, but we haven’t deployed it at a large scale quite yet. We are also looking at Storm.
While you are a CTO, you were a developer at one point and probably get your hands dirty at times. What makes Cloud Foundry so cool for developers?
Cloud Foundry has a command line interface, and AppFog has built an API. As I mentioned earlier, this gives developers the power of scripting. We spend more time coding and less time dealing with the foundational platform. So, all deployment tasks—infrastructure, new instances, deploying code, unit testing, integration testing, screen tests—all of this can be scripted. We push a button to trigger these processes. While this is possible with any modern infrastructure, Cloud Foundry really gives us the ability to stay at a high level in the stack and avoid getting into details.
We also really like the separation between applications and code. When we write the deployment manifest and need services like MySQL or Redis, we just tell the system we need an instance of it in a few lines of configuration without having to worry about the config of the underlying service. The underlying stuff is all handled by the platform.
We have gotten off the ground very quickly. In fact, Facebook has this concept of hiring developers to deploy code in the same day they started. Now, we have the same type of environment—one of our new developers can deploy code the same day they start with shrebo. This is one of the most exciting facts about Cloud Foundry—we can have a small team of 4 people work on the app and run the infrastructure, and we can scale people this way too. Five years ago, it would have required 10 or more people to run this same infrastructure and do development.
In terms of monitoring, are you using any of Cloud Foundry’s built in capabilities?
Well, we aren’t using the Cloud Foundry health check services API directly. We decided to use New Relic as the application-level performance metrics monitor. From outside, we use Pingdom to verify uptimes. New Relic as extremely easy to plug into Cloud Foundry applications—they have a Python extension that works out of the box with Cloud Foundry. As described we use RabbitMQ to do app-level event processing, but we also use it to send New Relic custom events to their services infrastructure.
As a CTO/CIO level person with a financial services background, you have a clear handle on ROI, C-level metrics, and risk management. What about Cloud Foundry is powerful from this perspective?
If I talk about this from my banking background, I can easily see how Cloud Foundry produces efficiency and effectiveness—this helps reduce costs and risk. Let me explain.
When we release code without Cloud Foundry, it might take 4-6 months at a traditional bank with more complexity and legacy systems. With Cloud Foundry, you can reduce that time to days or weeks. There is an order of magnitude level of improvement in terms of these process metrics. There are fewer people involved, it is easier for developers to fix problems, we can scale dynamically without emailing anyone—this all reduces cost and time, and as a result increases the productivity of the whole organization
In terms of risk, Cloud Foundry clearly reduces operational risk. This is largely related to the lower number of people that need to be involved. For example, if an app shows signs of crashing, we don’t have to involve a team to resolve. A developer can fix the code, and an automated, daily build can update the problems or a button can redeploy without five people having to coordinate on a conference call or group chat. As well, I’ve described how the scale and uptime scenarios work—this reduces downtime and ensures SLA support. This is particularly important for mission-critical, revenue generating apps. So, Cloud Foundry has a direct impact on the risk of our top and bottom line.
Would you mind sharing an architecture slide on your stack?
Sure, here see below. We use HTML5/Bootstrap, JSON/REST, Redis, MongoDB, RabbitMQ, MySQL, and Python/Django for the online services or real-time runtime. There is some overlap here with our batch or periodic workloads. This part of the architecture is another conversation all together. However, we use R, Elastic Search, Storm, Apache Hadoop®, and much more. The infrastructure includes Nginx, Varnish, Gunicorn, Cloud Foundry, Cloudinary, Searchly, Amazon AWS, Mailgun, and GlobalSMS.
Thank you so much, is there anything you’d like to add from a personal perspective? What do you like to do in your off time? Anything you’d like to accomplish before you leave this little rock we call Earth?
Sure. In my spare time I like to spend time with friends and family. I also very much enjoy to ride the bike in the woods, or sail that very boat that we used to share, which is based on a small lake in Switzerland. In extension of this, I plan to do a lot more sailing at sea, in fact one of my dreams is to become a certified skipper for maritime sailing yachts.
Editor’s Note: Apache, Apache Hadoop, Hadoop, and the yellow elephant logo are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries.
About the Author
