Posts written by Chad Lung
It’s been a while since my last post on Project Meniscus, which is an open-source, Apache 2 Licensed, cloud-scale logging service that collects logging data from cloud servers and services, makes the data easily searchable through ElasticSearch, and dispatches it into numerous other data stores, including MongoDB and Hadoop. Today I want to update everyone about the current status of the project and our future plans.
Dream big: that is our vision on the Rackspace Project Meniscus team. In one of our dreams, we provide a top-tier Logging-as-a-Service (LAAS) solution for the cloud. In another, we are accepted as an incubator project within OpenStack. These are lofty dreams, but we are a focus-driven team, and our dreams are our goals.
Project Meniscus is a better focusing lens for system and application events. It is completely open source (Apache 2 License) and headed by John Hopper, the original author of both the Repose and Atom Hopper projects. Both of these projects have seen great success within Rackspace as well as adoption around the world by many companies. These projects continue to move forward and benefit from their initial startup as open- source projects; they also have been proven to scale to the demands of the Cloud.
Chad Lung is a software engineer on the Rackspace Cloud Integration team and is the maintainer of Atom Hopper. Be sure to check out his personal blog at http://www.giantflyingsaucer.com/blog/ and follow @chadlung on Twitter.
I recently wrote an article introducing Repose which is a sponsored open-source project that is built to scale for the cloud. Repose is used within Rackspace as a a key element of our internal OpenStack.
This story is contributed by Chad Lung, a software engineer on the Rackspace Cloud Integration team. Chad is the lead maintainer of Atom Hopper project. Be sure to check out his personal blog at http://www.giantflyingsaucer.com/blog/ and follow @chadlung on Twitter.
What if you had a tremendous mountain of data, broken up and stored across thousands of servers, and your client wanted some specific portion of that data? You could assemble the whole mountain and send the whole thing to your client, leaving the client to pick out what's needed. But there are reasons you split it up in the first place: it’s too big to store in one place or to transfer without interruption. Additionally there are reasons you manage the data, including security and privacy, so this mountain moving might not be a good idea.