1. Code to Cloud with Megam and
Opennebula
Kishorekumar Neelamegam
Varadarajan Narayanan
Megam Systems

2. The cloud ecosystem

3. Cloud Journey

4. Moving to cloud
● Migration of development to production is a nightmare.
● Setting up an app environment takes ages.
● Most PAAS available today are coupled to single or few vendors.
● No backup and DR solutions in place.
● On demand auto scaling in a hybrid cloud environment is not feasible.
● Cloud add-ons for monitoring, logging, databases have fancy price tags.
● On site IT infrastructure, private cloud.
● Multiple IAAS vendors.
● SAAS is siloed.

5. What if we can ….
● Deploy in any cloud - Private and public Clouds or hybrid
● Capture repetitions and use canned pre-built recipes
● Scale seamlessly
● Use multiple cloud storage solutions
● Use any framework - Java, Play, Ruby on Rails, Node.js, Akka … and any source
cloud - Github , Bitbucket , Cloudforge ….
● Monitor, log and manage my apps
● API driven
● Integrate continuously with ALM & SDLC
● Avoid vendor lock in by sticking to open standards and open source

7. Megam features
SaaS - Users
Iaas - Providers
PaaS - Developers

8. Overview of Megam
Available as SaaS , installable software and as a packaged product - Megam Cloud in a box

9. Megam internal architecture
Major improvements in Megam 0.5 after
Opennebula day Florida
● Docker support with Visual docker
● CAMP/TOSCA compliance
● Cloud-in-a-box

10. Docker support for Opennebula

11. Why Containers ?
Infrastructure as a Service (IaaS) and Platform as a Service
(PaaS) instead of simplifying IT infrastructure have added a
layer of complexity .As a result, software developers are
spending increasing amounts of their time managing software
deployments instead of writing software.
● Basic:Because containers share the host kernel,
binaries and libraries, can be packed even denser
than typical hypervisor environments.
● Implied :Containers provide a clean separation of
concerns between development and operations
dependencies. In summary, changes are no longer
made to production, changes are made to containers,
and containers have a finite life-cycle that is optimized
for developer productivity and operational simplicity.
Kernel Namespaces and Cgroups became the defacto
standard for creating linux containers and is used by most of
the companies who have containerized technology, LXC,
Docker, ZeroVM, Parallels, etc.
vs

12. “Dockerisation” by various vendors

13. Openstack and Docker
Many changes have been incorporated since Havana release .Openstack Heat does the driving while the container engine is
setup and run inside of a cloud instance. The nova driver is now part of stackforge and will possibly try to rejoin the nova code
base in Juno. Support for Cinder also has been added.

14. AWS and Docker
Elastic Beanstalk is a platform-as-a-service technology from Amazon which lets developers cede
capacity provisioning, load balancing, auto-scaling and application health monitoring to AWS in
exchange for ease of use.Beanstalk has now been upgraded to support deploying and launching
applications containerized through Docker.
Any Docker image can be deployed this way, whether from Docker's public repository or from one's
own private store of containers. Users are left to create a .JSON file that describes the image to be
used and a few other notations, and even that's not mandatory because an existing Dockerfile, as they
are called, will typically work as-is.
Some additional configuration might be needed to set up external resources (a database to be used
by the application, for example), but Elastic Beanstalk already has configuration options to allow
deployment of a database to go with a Beanstalk-managed app.

15. Google and Docker
Google has been using Linux containers in its data centers for the better part of a decade. Across
Gmail, search, Google Drive, and whatever else, Google has been taking advantage of the technology
to run web-scale services with fewer headaches and a higher quality of service. They also use
“Omega” which Google’s own container scheduling technology.
Google released Kubernetes -- Greek for "helmsman," as on a ship -- its homegrown solution for
orchestrating and managing Docker containers at scale, making sure they smoothly replicate
according to schedule.
Container-optimized Google Compute Engine images are Debian images with a few additions:
● The Docker runtime is pre-installed, so you're ready to create containers as soon as your
instance is up.
● The image includes an agent that handles container manifest files, to create and monitor
containers automatically.
Google consolidated this move by calling this Google Container Engine ( Alpha)

16. Openshift and Docker
In order to integrate Docker in to Openshift (PaaS) , Red Hat provides a tool called
Gears. Gears are native containers built from cgroups and namespaces that run the
workloads. Openshift integrates Docker inside their Cartridge and Gear system by using
Docker Images with metadata as a Cartridge and using Docker Containers as Gears
(containers) based on the Cartridge.
Project Atomic is also a major component of their Docker system. Like CoreOS,the
Atomic host is a lightweight operating system that has been assembled out of upstream
RPM content and optimised to run applications in Docker containers. Hosts based on
Red Hat Enterprise Linux and Fedora are available now. Hosts based on CentOS will be
available soon. Project Atomic hosts inherit the full features and advantages of their base
distributions. This includes systemd, which provides container-dependency management
and fault recovery. It also includes journald, which provides secure aggregation and
attribution of container logs.

17. Megam and Docker
Some of the advanced features provided
by Megam Docker service
● We provide a “Dockerised-VM”
(CentoS 7) to create a cluster which
can be launched in any IaaS. thus
avoiding lock-in with the platform
provider like GCE , AWS and
maintain neutrality as far as IaaS is
concerned.
● Multi-tenancy security
● Maintain developer focus A level
above Github and other source code
repositories multiple source code
(Github , Assembla, SCM manager
Gogs)
● Visual designer for Docker

18. Megam and Docker

19. Megam standards

20. Cloud Applications Management
Platform
There are multiple commercial PaaS offerings in existence using languages such as
Java, Python and Ruby and frameworks such as Spring and Rails. Although these
offerings differ in such aspects as programming languages, application frameworks,
etc., there are inherent similarities in the way they manage the lifecycle of the
applications that are targeted for, and deployed upon them. The core proposition of this
specification is that these similarities can be leveraged to produce a generic
application and platform management API that is language, framework, and platform
neutral.
CAMP is the first major public effort to produce a specification of a management
interface for PaaS, as well as a packaging format for moving applications between
clouds.

21. Topology and Orchestration Specification for
Cloud Applications - TOSCA
TOSCA will enable the interoperable description of application and infrastructure
cloud services, the relationships between parts of the service, and the operational
behavior of these services (e.g., deploy, patch, shutdown) independent of the supplier
creating the service, and any particular cloud provider or hosting technology. TOSCA
will also enable the association of that higher-level operational behavior with cloud
infrastructure management.
This capability will greatly facilitate much higher levels of cloud service/solution
portability without lock-in, including:
● Portable deployment to any compliant cloud
● Easier migration of existing applications to the cloud
● Flexible bursting (consumer choice)
● Dynamic multi-cloud provider applications

22. Dense VM
PaaS vendors typically hide the IaaS
complexities and use containers to
isolate.
To isolate users, we use a managed VM.
To provide more value we allow packing
multiple in one VM. Typical scenario is
Liferay + MySQL plus a test application
in one VM)
Developers can quickly run services to
test apps, full blown VM doesn’t have to
be spun.

23. Visual designer
An Application Topology
● Infrastructure (Cloud)
● Platform (App)
● Services (Databases,
Queue, .)
Relationship between
components
● What is hosted on what ?
● What is connected to what ?

24. Visual Designer for Docker
● Launch the visual
designer
● Users launch the
Docker cluster on any
cloud.
● This has docker built in
with systemd using
CentOS 7,
● Compose an apps with
the url of dockerhub
registry

25. Megam Cloud in a box

26. Cloud in a box
Benefits of moving to cloud like scalability,
reliability, efficiency and ease of
management is not restricted to public or
private cloud. Megam takes full
cognisance of this fact and offers “Cloud-in-
a-box” concept to deploy a private
cloud in any configurable shared
computing resource like colocated servers
or servers on premise.
Cloud in a box offers a complete cloud
solution including Iaas (Opennebula),
Paas (Megam) , and High availability
(DRBD proxy) and cloud bursting to public
clouds using plugins.

27. Building a cloud in a box

28. Megam Road map
1) Native Docker/LXC/Rocket for OpenNebula
2) Bitcoin and Megam
3) Analytics as Service (IoT)
4) HA in CIB
a) Federate CIB
b) CIB with DR
5) Megam HA for apps.

29. Questions ?

30. Thank you !