Though the official Cloud Foundry documentation provides some general guidelines on how to create a buildpack, it does not demonstrate the in-depth behavior of scripts and how to test and debug buildpacks. In this post, I will try to fill in the missing gaps.
On Dec 17, the Cloud Foundry community will celebrate its achievements at the year-end party in Palo Alto. 10+ speakers will discuss the blueprints for the future of the CF Foundation and Cloud Foundry in the era of container-driven DevOps. Join the sessions I’ll take part in:
- 6:45–7:10 pm, Community Lightning Talks
- 7:35–7:45 pm, Lightning Panel: Will Docker Eat Cloud Foundry’s Lunch?
At the Lightning Panel together with James Watters of Pivotal, we will discuss the state of integration between Cloud Foundry and Docker; what Diego will and will not resolve when it comes to the growing tension between two darlings of the cloud; what is missing in an attempt to standardize the containers the POSIX-style; as well as other challenges and possible solutions.
We also wanted to hold a “Cloud Foundry 101″ workshop on Dec 18 (to help you learn how to deploy CF with BOSH-lite and create your first apps on CF), however for some tech reasons we need to move it to another date. Probably, either late December 2014 or January 2015. Sorry, guys, we’ll do our best to prepare for it as needed. As of now, we expect that Dave Nielsen, Cloud Computing Evangelist and Consultant, and Leandro Cacciagioni, Senior DevOps Engineer at Altoros, will help you to discover how Cloud Foundry solves the issues of portability, scalability, extensibility, and reliability. We’ll announce the new date very soon, track our updates at @altoros.
The launch of the Cloud Foundry Foundation is not only an important milestone for our community, but a defining moment for the future of many industries.
Altoros’s commitment to Cloud Foundry began as a way of helping an open source PaaS to become more consumable. One day, my colleague and I were showing what Cloud Foundry is to executives of a $4B pharmaceutical and medical device company. Little did we know that it could save thousands of human lives. These were the early days of what would become software-defined drug delivery.
This commitment resulted in Altoros deploying software assembly lines that help companies to re-invent their industries. To deploy the assembly lines, we leverage products and solutions offered by the Cloud Foundry ecosystem.
Cloud Foundry went through rounds of customer discovery and validation. It is seen both as an application delivery platform and a digital change agent. That is the magic of Cloud Foundry.
A lot has changed in the Juju orchestration tool and the Cloud Foundry Juju Charm, since our latest blog post about them. In this new post, I will overview the new features and provide two guides on installing CF, taking into account these updates. You will learn about:
- The new Cloud Foundry Juju charm implementation and some of its features
- How to deploy Cloud Foundry automatically with the latest CF Juju charm
- How to deploy Cloud Foundry manually using the config file
- How to customize your CF deployment by editing the config file
- How to upgrade CF with Juju
Join the upcoming East Bay meetup to learn when to use Docker, Diego, or Cloud Foundry and how to deploy Spring Boot-based Microservices with Docker—together with Chris Richardson, the founder of the original Cloud Foundry. In addition to Mr. Richardson’s presentation, I will speak about the opportunities that Diego brings to both Docker and Cloud Foundry users and likely scenarios of Docker evolution in clustered systems.
A video recording of the event:
Join tomorrow’s meetup in San Francisco to discuss how to store and analyze sensor-generated data—together with Animesh Singh, Syed Zaidi, Dwight Ford, and Nicholas Vargas of the IBM Bluemix team. In addition, I will identify four levels of IoT maturity and share how an S&P 500 company created an IoT business model using Docker containers and Cloud Foundry-based microservices.
Not in San Francisco? You can watch the live streaming of the meetup on this page starting from 6 PM, Nov 18.
Recording of the live stream is now available:
Some Cloud Foundry components must be available, even if Router fails. Admin UI, a monitoring tool from the Cloud Foundry incubator, is a good example of a utility that you want to have access to no matter what. Getting updates directly from the NATS messaging bus, it gives admins access to CF components, their logs, statistics on DEAs and applications deployed to them, user rights, and other things not available in the Cloud Foundry CLI.
BOSH releases help to achieve high availability by installing important components outside the main CF deployment. By doing so, you can avoid exposing them with Router or deploying them as apps. In addition, they provide the easiest way to bind Cloud Foundry components and custom services.
In this post, I share my experience with creating a BOSH release (not yet available at the time this was published) for a new version of Admin UI. I also provide a temporary workaround for those who need to deploy Admin UI now and cannot wait for the next BOSH release.
On Oct 23, HP launched Helion Development Platform—HP’s PaaS based on Cloud Foundry and integrated with HP Helion OpenStack. Below is a brief recap of the event.
Even if you have years of experience with data-intensive apps, selecting a NoSQL data store for a particular case out of dozens of options may be a daunting task. The variety of databases goes way beyond sheer numbers, so you have to carefully compare and benchmark several options before you can choose the most appropriate solution.
To help companies select the best database based on particular use cases, workloads, or requirements, we decided to come up with a handy template for evaluating NoSQL solutions. While many other comparisons focus only on one or two dimensions, we compiled a scoring framework that approaches the databases from 20+ angles (including performance, scalability, availability, ease of installation, maintenance, data consistency, fault tolerance, replication, recovery, etc.).
As a real-life example of such an evaluation benchmark, today we present “The NoSQL Technical Comparison Report” that provides an in-depth analysis of the leading NoSQL systems: Cassandra (DataStax), MongoDB, and Couchbase Server. Each of the databases was scored on a scale from 1 to 10 across 21 criteria.
With 29 charts and 30 tables, this paper features a scoring template for evaluating and comparing NoSQL data stores for your particular use case—depending on the weight of each criterion. We also give recommendations on the best ways to configure, install, and use NoSQL databases depending on their specific features.