On Saturday, Feb 28, some AppFog users with apps deployed to the AWS-AP datacenter began experiencing issues when attempting to manage applications via the CLI or Web Console.
In a nutshell, AppFog users have been unable to list, deploy, update or manage their applications running in the AWS-AP (Asia Pacific) datacenter. Applications already deployed have not been impacted – so unless you stopped your application shortly before the issue occurred – app access by end-users remains uninterrupted.
Our engineers initially believed the issue was resolved on Sunday, Mar 1, but it has since continued to sporadically re-occur. We are actively working to resolve this issue and restore full management functionality.
However, in the meantime, if you need to make updates to your application, we recommend you to clone your app via the cli to the AWS-US or CLC-US infrastructure using this command:
$ clone <src-app> <dest-app> [infra]
Cloning your app to a different datacenter will allow you to manage your applications. We will update this blog post with additional details once the issue has been resolved.
Andrew Higginbotham, the CenturyLink exec who helped bring that telco into the modern cloud computing era, is leaving the company after 14 years, Gigaom has learned. Higginbotham, who was SVP of cloud and technology, led CenturyLink’s $3.2 billion acquisition of Savvis in 2011 and subsequent purchases of AppFog, Tier […]
Big changes atop CenturyLink cloud as Higginbotham departs originally published by Gigaom, © copyright 2015.
As with most teams, we have different people working on different things. When I joined AppFog in August 2013, I was part of the Support Team. However, during the last eight months I’ve shifted to a Front-end Web Developer role, while still handling some support responsibilities as well. One of my first projects was to redesign our Zendesk Help Center to better serve our users. (Learn more about the redesign here.)
Over the last several months we’ve updated (or added) eight different Jumpstarts and Runtimes to make it easier for our users to quickly get started and launch their preferred development stack. We added banners indicating whether a Jumpstart or Runtime is in Beta, recently Updated or brand New. If you have suggestions for more Jumpstarts, please vote for them on our uservoice feedback page.
We’ve improved the team member management functionality on the Teams page (https://console.appfog.com/#teams). Previously, the “Accept” or “Decline” buttons would only become visible if you moused-over the Member Invite box. This was not intuitive for new users, so we dropped the “slide up” animation in favor of clearly displaying the buttons. We also updated the text to more clearly communicate which teams you belong to and who is on your team.
On our Plans page (https://console.appfog.com/#plans), we’ve replaced the table layout design with a box-style layout which more closely matches the rest of the web console. Each box still lists the plan’s features, but we think in a bit more eye-pleasing detail.
We’ve also made some updates to the buttons — the button states and labels has been modified slightly to give more information about your subscription plan and your options.
We’ve added a subscription status message to the top of the Web Console. We added this so you can easily see the status of your trial or subscription without having to go to the Account page. Below is list of the most common subscriptions details.
We hope these updates help make our Web Console more useable. If you have additional suggestions or ideas for how we can improve our user interface, please share them with us at http://feedback.appfog.com. And if you spot any UI anomalies or glitches, please let us know so we can get it resolved: firstname.lastname@example.org.
As a developer, using a Platform-as-a-Service (PaaS) to host your web app or service really simplifies your life. But despite the error handling you’ve embedded into your code :-), your web app or service can still crash or become unresponsive. (Note: Whether you’re running a web site, web application, RESTful API application, SOAP-based web service, or something else, for the rest of this article I’ll just call it an “application”).
As you probably already know, one of the big advantages to using AppFog is that your application will be automatically restarted if it crashes… however, there are also times when your app may not be responsive. There are several reasons this can happen:
Whatever the reason, if your app is not responsive, the AppFog platform will return an error page:
Today we are launching a new capability: Custom Error Pages. Although the default error page is unbranded, using a custom error page allows you to return an error page styled to match your application’s look-and-feel.
To set up a Custom Error Page for your application, login to the Web Console, open your app’s mission control page, and select the Custom Error Pages option from the left nav menu to edit the HTML directly. After applying the changes, click the preview link above the editor text box to see how your edits will appear to your users. (Note: The “Apply Changes” button only activates after you’ve made changes)
Alternatively, you can use the Custom Error Page Generator at the bottom of the page to customize your error message. We store the HTML for your Custom Error page, but to use a different CSS or image assets, you’ll need to embed the links to these resources in your HTML. For our default error page, we used Amazon’s S3 service for its simplicity and reliability. To learn more, please see the Custom Error Page doc.
In early 2010, late one Friday night, Lucas Carlson posted a link on Hacker News asking developers if they would be interested in a PHP-oriented Platform-as-a-Service (PaaS). By the next evening, hundreds of enthusiastic responses confirmed there was a significant demand for such a PHP-focused PaaS. He went to work hiring a team, building the platform, raising capital, and finally launching PHP Fog, a PaaS for PHP developers. Over the next two years, 10’s of thousands of developers signed up for the service, deploying their PHP apps onto PHP Fog and sharing insights into their experiences and challenges.
Lucas quickly realized that developers wanted to build cloud-ready applications using other languages besides PHP. So in 2011, the team went to work building a PaaS capable of supporting additional languages, native services (e.g. databases and other essentials options like databases and middleware) and a 3rd party add-on marketplace. The result, launched in Summer 2012, was AppFog, a multi-cloud, polyglot, platform-as-a-service based on the Cloud Foundry open source project.
It’s been two years since the PHP Fog became AppFog, and a lot has changed. In June 2013, CenturyLink acquired AppFog, and just five months later, one of the leading Enterprise-class cloud providers: Tier 3. Although the AppFog brand remained unchanged, Tier 3 became the CenturyLink Cloud. These acquisitions have positioned CenturyLink to meet the growing demand for cloud services as customers transition their IT workloads to the cloud. CenturyLink’s vision is to provide a single, unified platform that enables users to do everything from provisioning virtual machines and bare metal servers, to defining their networks, harnessing Big Data with Hadoop, and deploying modern, cloud-ready applications on AppFog v2 — all through a single pane of glass (*a figurative term, we’re still talking about the CenturyLink Cloud control panel).
So today, on the eve of Thanksgiving, we are excited to announce our own Thanksgiving Present: the General Availability release of PHP 5.4, PHP 5.5 and PHP 5.6 on AppFog. In addition, we have updated our WordPress 4.0 and Drupal 7 Jumpstarts to run on PHP 5.5. In the next few weeks we will add additional jumpstarts, including a “Cloudified” WordPress 4.0, Tomcat 7 with Servlet 3, and other framework updates.
To get started, login or signup for a 30-day trial. We’d love to learn about your experience using the new PHP runtimes on AppFog, whether you are upgrading existing apps, or launching new ones. Any and all feedback is welcome – the better we understand what you are building, the more effectively we can prioritize our product roadmap. Please share your feedback at http://feedback.appfog.com or email me directly: email@example.com.
The post Thanksgiving Present: GA Release of PHP 5.4, PHP 5.5, and PHP 5.6 appeared first on Platform as a Service Magazine.
On October 15, the Drupal Security Team reported a SQL injection vulnerability in Drupal 7 (https://www.drupal.org/SA-CORE-2014-005), affecting all Drupal core 7.x versions prior to Drupal 7.32. This FAQ on SA-CORE-2014-005 provides additional details.
The solution to remediate this vulnerability is to upgrade all Drupal 7.x sites to 7.32. This is a relatively simple task for AppFog users who have already deployed Drupal apps. Follow these steps below:
'af pull'to download your existing Drupal website code to an app folder on your local machine.
<drupal_app_folder>/sites/default/settings.php) to a separate location for later.
'af update <appname>'for your app. That’s it!
More detailed upgrade instructions are provided in this KB article.
The post Drupal v7.32 Update Available – SA-CORE-2014-005 Remediation Steps appeared first on Platform as a Service Magazine.
Shellshock is the nickname for a flaw in the GNU Bourne Again Shell, or “Bash”, which is a command-line shell processor used for sending commands on Unix and Linux-based operating systems. The flaw in Bash, which has been present for two decades, could allow an attacker to take complete control of a computer if the software is remotely accessible.
Our team immediately went to work and patched the AppFog Platform to protect both our assets and those of our users. We fully patched the first vulnerability in less than 8 hours, and have patched the second vulnerability as well. At this time, the AppFog Platform passes all (known) tests for CVE-2014-6271, -7169, -7186, and -7187.
As the situation continues to unfold (vulnerabilities CVE-2014-6277 & -6278 were announced Monday, September 29, but full details have not yet been published), we will continue to update our environment and post updates on our @AppFogHelp and @AppFog Twitter accounts.
While this defect primarily impacts web servers and *nix servers, AppFog users running Apple’s OS X, Linux or Unix variants locally should apply the Bash fixes as soon as they are published.
The post AppFog Patching Shellshock-related Vulnerabilities appeared first on Platform as a Service Magazine.
Last week we announced an important new partnership with Cloudbees to bring a native enterprise Jenkins service to Pivotal CF (PCF). This provided a first glimpse at the power of Pivotal Network, a service catalog for PCF. Pivotal Network allows any private PCF installation to import additional scalable platform services from Pivotal and a growing ecosystem of partners. PCF then manages the health and scalability of these services natively.
As Cloudbees joined the extended Pivotal ecosystem they also exited their hosted RUN@ PaaS business, which they had previously offered on AWS. In a thoughtful exit interview the talented Steve Harris compared their four year journey into PaaS market to a high risk polar expedition. As a fellow adventurer with Harris in the platform market since 2010, I would sum up my own experience and many of the conclusions of his blog with this chart:
The public platform space has been a brutal market for startups. The $212M Salesforce buyout of Heroku in late 2010 was a false positive, and confused VCs. The investments became irrationally exuberant and the results were predictably bad. Public PaaS startups were too early, under resourced and focused on the wrong segment to win big in this new market. VC funded plays such as Dotcloud, Appfog, Cloudbees, and even the mobile specialists Parse and Stackmob have all since ‘pivoted’ or been modestly absorbed into larger organizations.
Deep pocketed investment by the major cloud providers such as Google’s recent free $100k for startups made it even harder for independent cloud platforms to compete or raise additional funding (all while having to pay the IaaS providers).
Finally, as Harris observed Cloud Foundry executed well on a broad ecosystem play, creating the “Cloud Foundry effect”
“There is a Cloud Foundry effect: Cloud Foundry has executed well on an innovate-leverage-commoditize (ILC) strategy using open source and ecosystem as the key weapons in that approach.”
Pivotal’s popular shared Cloud Foundry service for developers, PWS, is priced at only $2.70/month for a small hosted application. Stuck between the rapid growth of AWS, Google, and the emerging enterprise standard of Cloud Foundry there just wasn’t margin left for the hosted alternative platforms to live on.
In contrast to the startup failures in the public PaaS market, the revenue in the private platform market is significant and growing exponentially. While many enterprises are leveraging public cloud, many of the “crown jewels” applications still reside in private data centers, along with the majority of IT budgets. This means that despite public cloud adoption, architectural standards often start in the private cloud landscape and extend out.
Executing in this segment generates large purchase orders but requires shipping installable enterprise software, multi-year R&D, and a large enterprise sales force (the last two points being beyond the scope of most VC-funded business plans). The deals are large because they tap into the enormous yearly spend on enterprise middleware currently dominated by innovation laggards like Oracle’s SOA Suite. These legacy products were designed for infrequently updated applications built for vertical scaling—two trends which are now out of date. As the Harris’ blog observed:
“Pivotal Cloud Foundry has produced partnerships with the largest, established players in enterprise middleware and apps. In turn, that middleware marketplace ($20B) is prime hunting ground for PaaS, and Cloud Foundry has served up fresh hope to IT people searching desperately for a private cloud strategy”.
While public only PaaS players have continued to exit the market, private software based PCF has racked up an impressive parade of enterprise customers migrating from Oracle middleware to a next generation private cloud architecture. In June, more than a thousand enterprise users gathered for the Cloud Foundry summit, speaking to the remarkable benefits of building an application centric private cloud.
Early pioneers like Corelogic’s Richard Leurig are betting their company’s future on a next generation platform architecture and breaking down years of siloed applications on heterogeneous infrastructures. The market is waking up from years of dealing with the complexity of legacy products and demanding a cloud API integrated solution. They are also transforming their development processes to be more agile, anchored on continuous integration with systems like Jenkins. This is resulting in earmarked budgets for large private PaaS build outs.
As enterprises adopt PCF, it is changing their whole concept of private cloud. Line of business developers gain immediate self service access to rapidly test and deliver applications and APIs. Monsanto observed an immediate 50% reduction in LOB development time and costs with PCF and plans to standardize the company on it in 2015. For infrastructure teams PCF’s minimal IaaS requirements and deep platform provisioning automation provides immediate private cloud features with just a few clicks and a thirty minute install time.
Customer demand to extend the platforms’ services catalog with Jenkins, Cassandra, Elastic Search, etc is overwhelming. Even enterprise stalwarts such as SAP, and SAS have announced customers are pushing them to offer their software on Cloud Foundry based private clouds. Almost every day brings an inquiry from an existing ISV whose customers are migrating to the platform who wants to be part of the PCF service catalog.
Heading into 2015, we are hiring hundreds of additional developers, operations, marketing and sales professionals, and ramping every part of the team to take on our forty billion dollar enterprise opportunity.
The public only PaaS meme centered on hosting, and missed the true revolution in software architecture happening in enterprises. This allowed Cloud Foundry to germinate in R&D for several years and surprise existing vendors, who prepared for the change merely by offering their existing legacy products on demand. Oracle kept its decade old middleware architecture focused on heavyweight J2EE but enterprise applications are moving from heavyweight client-server legacy model to a mobile centric paradigm dominated by REST APIs and microservices.
The production ready PCF platform has emerged as a way for enterprises to deliver on an ambitious private cloud initiative, ready for mobile APIs and microservices based applications. It delivers highly scalable, highly available services, fully automated on any cloud, with an easy to use developer API perfect for agile teams.
Using PCF is believing, and after one recent successful pilot, a bemused Fortune 50 CIO asked me, “IBM has been promising me this level of simplicity and automation for years, why are you able to pull it off while they failed?” I answered, “Only by bringing the discipline of modern cloud architecture to enterprise applications were the efficiency gains you witnessed possible. No one has ever brought a cloud native platform to the enterprise datacenter—until now.”
The next few years of this expedition are going to be very interesting!
Here at AppFog we are happy to announce the launch of our new help center! For the past few weeks our team has been hard at work updating the support pages in order to provide a more seamless user experience for AppFog customers.
This help center invites users to participate within a thriving developer-friendly community and provides a comprehensive wealth of knowledge about the system.
One new feature is a help center search function to provide you the answers to your burning
questions when launching an application on the AppFog PaaS.
As we have in the past, our help portal also allows customers to submit detailed support tickets regarding account or application specific issues, now with an updated user experience.
In addition we have launched the AppFog support forums to provide increased public user interaction between developers.
We are excited for our users to explore this new help center and to learn more about the PaaS that developers love, AppFog!
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?
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 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, 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.