What is Docker?

Organizations in today’s world look forward to transforming their business digitally but are constrained by the diverse portfolio of applications, cloud, and on-premises-based infrastructure. Docker solves this obstacle of every organization with a container platform that brings traditional applications and microservices built on Windows, Linux, and mainframe into an automated and secure supply chain.

Docker is a software development tool and a virtualization technology that makes it easy to develop, deploy, and manage applications by using containers. A container refers to a lightweight, stand-alone, executable package of a piece of software that contains all the libraries, configuration files, dependencies, and other necessary parts to operate the application.

In other words, applications run the same irrespective of where they are and what machine they are running on because the container provides the environment throughout the software development life cycle of the application. Since containers are isolated, they provide security, thus allowing multiple containers to run simultaneously on the given host. Also, containers are lightweight because they do not require an extra load of a hypervisor. A hypervisor is a guest operating system like VMWare or VirtualBox, but instead, containers run directly within the host’s machine kernel.

Containers provide the following benefits: 

• Reduced IT management resources 
• Reduced size of snapshots 
• Quicker spinning up apps
• Reduced and simplified security updates
• Less code to transfer, migrate and upload workloads

To start your Docker journey, contact us to learn more about Cloud Academy’s in depth Docker Learning Path.

What is a Virtual Machine?

A Virtual Machine (VM), on the other hand, is created to perform tasks that if otherwise performed directly on the host environment, may prove to be risky. VMs are isolated from the rest of the system; the software inside the virtual machine cannot tamper with the host computer. Therefore, implementing tasks such as accessing virus-infected data and testing of operating systems are done using virtual machines. We can define a virtual machine as: 

A virtual machine is a computer file or software usually termed as a guest, or an image that is created within a computing environment called the host. 

A virtual machine is capable of performing tasks such as running applications and programs like a separate computer making them ideal for testing other operating systems like beta releases, creating operating system backups, and running software and applications. A host can have several virtual machines running at a specific time. Logfile, NVRAM setting file, virtual disk file, and configuration file are some of the key files that make up a virtual machine. Another sector where VMs are of great use is server virtualization. In server virtualization, a physical server is divided into multiple isolated and unique servers, thereby allowing each server to run its operating system independently. Each virtual machine provides its virtual hardware, such as CPUs, memory, network interfaces, hard drives, and other devices. 

VMs are broadly divided into two categories depending upon their use:

1. System Virtual Machines: A platform that allows multiple VMs, each running with its copy of the operating system to share the physical resources of the host system. Hypervisor, which is also a software layer, provides the virtualization technique. The hypervisor executes at the top of the operating system or the hardware alone.
2. Process Virtual Machine: Provides a platform-independent programming environment. The process virtual machine is designed to hide the information of the underlying hardware and operating system and allows the program to execute in the same manner on every given platform.

To learn more about VMs, check out Cloud Academy’s Virtual Machines Overview Course. If you don’t already have a Cloud Academy account, contact us for a FREE 7-day trial.  

Although several VMs running at a time may sound efficient, it leads to unstable performance. As the guest OS would have its kernel, set of libraries and dependencies, this would take up a large chunk of system resources.

Other drawbacks include inefficient hypervisor and long boot uptime. The concept of Containerization overcomes these flaws. Docker is one such containerization platform.

Docker vs Virtual Machine: main differences

The following are the significant differences between Docker and virtual machines.

OS Support and Architecture

The main difference between Docker and VMs lies in their architecture, demonstrated below.

VMs have the host OS and guest OS inside each VM. A guest OS can be any OS, like Linux or Windows, irrespective of the host OS. In contrast, Docker containers host on a single physical server with a host OS, which shares among them. Sharing the host OS between containers makes them light and increases the boot time. Docker containers are considered suitable to run multiple applications over a single OS kernel; whereas, virtual machines are needed if the applications or services required to run on different OS. 

Security

The second difference between VMs and Docker is that Virtual Machines are stand-alone with their kernel and security features. Therefore, applications needing more privileges and security run on virtual machines. 

On the flip side, providing root access to applications and running them with administrative premises is not recommended in the case of Docker containers because containers share the host kernel. The container technology has access to the kernel subsystems; as a result, a single infected application is capable of hacking the entire host system. 

Portability

Another relevant Docker vs Virtual Machine difference is about portability: VMs are isolated from their OS, and so they are not ported across multiple platforms without incurring compatibility issues. At the development level, if an application is to be tested on different platforms, then Docker containers must be considered. 

Docker container packages are self-contained and can run applications in any environment, and since they don’t need a guest OS, they can be easily ported across different platforms. Docker containers can be easily deployed in servers since containers being lightweight can be started and stopped in very less time compared to virtual machines.

Performance

The last main Docker vs VM difference refers to performance: Virtual Machines are more resource-intensive than Docker containers as the virtual machines need to load the entire OS to start. The lightweight architecture of Docker containers is less resource-intensive than virtual machines. 

In the case of a virtual machine, resources like CPU, memory, and I/O may not be allocated permanently to containers — unlike in the case of a Docker container, where the resource usage works with the load or traffic. 

Scaling up and duplicating a Docker container is simple and easy as compared to a virtual machine because there is no need to install an operating system in them.

Apart from the major differences between Docker and VMs, some other ones are summarized below: 

Should I choose Docker or Virtual Machine (VM)? 

It won’t be fair to compare Docker and virtual machines since they are intended for different use. Docker, no doubt is gaining momentum these days, but they cannot be said to replace virtual machines. In spite of Docker gaining popularity, a virtual machine is a better choice in certain cases. Virtual machines are considered a suitable choice in a production environment, rather than Docker containers since they run on their own OS without being a threat to the host computer. But if the applications are to be tested then Docker is the choice to go for, as Docker provides different OS platforms for the thorough testing of the software or an application. 

Furthermore, a Docker container uses docker-engine instead of a hypervisor, like in a virtual machine. As the host kernel is not shared, using docker-engine makes containers small, isolated, compatible, high performance-intensive, and quickly responsive. Docker containers have comparatively low overhead as they have compatibility to share single kernel and application libraries. Organizations are making use of the hybrid approach mostly as the choice between virtual machines and Docker containers depend upon the kind of workload offered. 

Also, not many digital operational companies rely on virtual machines as their primary choice and prefer migrating towards using containers as the deployment is comparatively lengthy and running microservices is also one of the major challenges it possesses. However, they are still some firms that prefer virtual machines over Dockers whereas companies who are interested in enterprise-grade security for their infrastructure prefer to make use of Dockers. 

Finally, containers and Docker are not in conflict with virtual machines, they are both complementary tools for different workloads and usage. Virtual machines are built for applications that are usually static and don’t change very often. Whereas, the Docker platform is built with a mindset to be more flexible so that containers can be updated easily and frequently. 

Will containers ever replace virtual machines? Comment your thoughts below or give further suggestions.

For more on our content or to schedule a demo with one of experts contact us today!

The post Docker vs. Virtual Machines: Differences You Should Know appeared first on Cloud Academy.

Let’s start our discussion by setting a foundation of what microservices are. Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple Application Programming Interfaces (APIs).

Microservices have become increasingly popular over the past few years. They are an example of the modular architectural style, based on the philosophy of breaking large software projects into smaller, independent, and loosely coupled parts, which has gained prominence among developers for its dynamic and agile qualities in API management and execution of highly defined and discrete tasks.

Simply stated, microservices are really nothing more than another architectural solution for designing complex – mostly web-based – applications. Microservices have gained prominence as an evolution from SOA (Service Oriented Architecture), an approach that was designed to overcome the disadvantages of traditional monolithic architectures. In this blog post, we’ll explore the evolution of development from monolithic architectures toward microservices and its underlying justifications, as well as the pros and cons of microservices.

If you an your team are new to microservices, check out Cloud Academy’s Training Library. From beginner to advanced, the Training Library is loaded with courses to introduce you to microservices or advance your skills on how to build microservices solutions or APIs.

If you’d like to find out how Cloud Academy can be integrated into your company and help you to reach your tech goals, contact us for a free demo. 

The history of microservices

Let’s start with a simple example: Suppose I need to build a classic web application using Java. The first thing I will do is design a Presentation Layer (the user interface), followed by an Application Layer, which handles all of the business logic. This is followed by an Integration Layer to enable loose coupling between various components of the Application Layer. Finally, I will design a Database Layer that will be accessible to the underlying persistence system.

To run the entire application, I will create either a EAR or WAR package and deploy it on an application server (like JBoss, Tomcat, or WebLogic). Because I have packaged everything as an EAR/WAR, my application becomes monolithic in nature, which means that even though we have separate and distinguishable components, all are packaged together.

Here’s an illustration of an example monolithic architecture:

You may already be familiar with the characteristics of monolithic applications depending on your development experience. However, this example also stands to illustrate some of the challenges developers and architects face with this kind of design.

Here are the flaws:

• As the application grows, so does the associated code base, which can overload your development environment each time it loads the application, reducing developer productivity.
• Because the application has been packaged in one EAR/WAR, changing the technology stack of the application becomes a difficult task. With this kind of architecture, refactoring the code base becomes difficult because it’s hard to predict how it will impact application functionality.
• If any single application function or component fails, then the entire application goes down. Imagine a web application with separate functions including payment, login, and history. If a particular function starts consuming more processing power, the entire application’s performance will be compromised.
• Scaling monolithic applications such as the one described in the example can only be accomplished by deploying the same EAR/WAR packages in additional servers, known as horizontal scaling. Each copy of the application in additIonal servers will utilize the same amount of underlying resources, which is inefficient in its design.
• Monolithic architecture impacts both the development and application deployment stage. As applications increase in size, it’s even more important that developers be able to break their applications down into smaller components. Because everything in the monolithic approach is tied together, developers cannot work independently to develop or deploy their own modules and must remain totally dependent on others, increasing overall development time.

With these thoughts in mind, let’s explore the value of microservices and how they can be used to provide the flexibility that’s lacking in monolithic architectures.

The theory behind microservices

One of the major driving forces behind any kind of architectural solution is scalability. Many of our peers in the software architecture and development world have gravitated towards a book called The Art of Scalability. The book’s defining model was the Scale Cube, which describes three dimensions of scaling:

As you can see, the X-axis represents horizontal application scaling (which we have seen is possible even with monolithic architecture), and the Z-axis represents scaling the application by splitting similar things. The Z-axis idea can be better understood by using the sharding concept, where data is partitioned and the application redirects requests to corresponding shards based on user input (as is commonly done with databases).

The Y-axis represents functional decomposition. In this approach, various functions can be seen as independent services. Instead of deploying the entire application once all the components are available, developers can deploy their respective services independently. This not only improves developer time management but also offers greater flexibility to change and redeploy their modules without worrying about the rest of the application’s components. You can see how this is different from the earlier diagram which showed a monolithic design:

Advantages of microservices

The advantages of microservices seem strong enough to have convinced some big enterprise players such as Amazon, Netflix, and eBay to adopt the methodology. Compared to more monolithic design structures, microservices offer:

• Improved fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
• Eliminate vendor or technology lock-in: Microservices provide the flexibility to try out a new technology stack on an individual service as needed. There won’t be as many dependency concerns and rolling back changes becomes much easier. With less code in play, there is more flexibility.
• Ease of understanding: With added simplicity, developers can better understand the functionality of a service.
• Smaller and faster deployments: Smaller codebases and scope = quicker deployments, which also allow you to start to explore the benefits of Continuous Deployment.
• Scalability: Since your services are separate, you can more easily scale the most needed ones at the appropriate times, as opposed to the whole application. When done correctly, this can impact cost savings.

Disadvantages of microservices

Microservices may be a hot trend, but the architecture does have drawbacks. In general, the main negative of microservices is the complexity that any distributed system has.

Here’s a list of some potential pain areas and other cons associated with microservices designs:

• Communication between services is complex: Since everything is now an independent service, you have to carefully handle requests traveling between your modules. In one such scenario, developers may be forced to write extra code to avoid disruption. Over time, complications will arise when remote calls experience latency.
• More services equals more resources: Multiple databases and transaction management can be painful.
• Global testing is difficult: Testing a microservices-based application can be cumbersome. In a monolithic approach, we would just need to launch our WAR on an application server and ensure its connectivity with the underlying database. With microservices, each dependent service needs to be confirmed before testing can occur.
• Debugging problems can be harder: Each service has its own set of logs to go through. Log, logs, and more logs.
• Deployment challengers: The product may need coordination among multiple services, which may not be as straightforward as deploying a WAR in a container.
• Large vs small product companies: Microservices are great for large companies, but can be slower to implement and too complicated for small companies who need to create and iterate quickly, and don’t want to get bogged down in complex orchestration.

Of course, with the right kind of automation and tools and the properly trained staff, all the above drawbacks can be addressed.

Deployment of microservices

Now that we understand microservices, how are they deployed?

The best way to deploy microservices-based applications is within containers, which are complete virtual operating system environments that provide processes with isolation and dedicated access to underlying hardware resources. One of the biggest names in container solutions right now is Docker, which you can learn more about in our Getting Started Course.

Virtual machines from infrastructure providers like Amazon Web Services (AWS) can also work well for microservices deployments, but relatively lightweight microservices packages may not leverage the whole virtual machine, potentially reducing their cost-effectiveness.

Code deployments can also be completed using an Open Service Gateway Initiative (OSGI) bundle. In this use case, all application services will be running under one Java virtual machine, but this method comes with a management and isolation tradeoff.

How to move forward with microservices

As application development trends continue to evolve, the debate between using microservices or leveraging traditional monolithic architectures will only become more pronounced. In the end, developers must do their due diligence and understand what works for their specific use cases.

For smaller companies, starting with a monolithic application can be simpler, faster, and cheaper — and if the product hasn’t gotten too mature, it can still be migrated to microservices at an appropriate time. The huge companies with millions of users are obvious examples of the best use case for microservices, as they need to ensure the uptime, scalability that the added modularity can provide.

A quick video review of the advantage of microservices

Check out our video below where Cloud Academy DevOps lead Jeremy Cook compares monolithic vs microservice architectures. And you can get further info straight from the source: our course on .Net Microservices – Refactors and Design.

Resources to get started with microservices

If you’re looking to use microservices, get started today with these resources on Cloud Academy:

• Build Microservices on AWS Using Serverless: Watch this on-demand webinar to learn how to build event-driven microservices on top of AWS Lambda, Twilio, Amazon Rekognition, and IMDbPy API using the Serverless framework.
• Build RESTful Microservices with AWS Lambda and API Gateway: Get practical experience as you design your own resources structure, add dynamic routing parameters, and develop custom authorizations logic.
• Explore all of our microservices courses in the Cloud Academy Content Library.

To learn more about Cloud Academy’s course offerings and certification programs, contact one of our experts for a free demo.

The post Advantages and Disadvantages of Microservices Architecture appeared first on Cloud Academy.

This is the first article in a series to introduce our members to the prerequisites to learning cloud computing. This was a question I was emailed countless times from our users, and while we have Learning Paths, AWS Certification Prep Learning Paths, Hands-on Labs, and Skill Assessments to help guide you on this journey, can provide a useful guide on this topic.

Prerequisites to learning cloud computing

At one point or another, most new members of Cloud Academy ask us, “What are the prerequisites and requirements to start learning cloud computing?”

In this article, we’ll give you the necessary information needed to answer this and make sure you’re ready to start learning cloud computing without any worries.

The term “cloud computing” refers to a wide area of information technology (IT) that touches on the following areas: 

• Hardware infrastructure
• Software infrastructure
• Data center facilities
• Virtualization technologies
• Software engineering concepts

All these areas are connected and can provide you with a strong background as you start exploring and working with cloud computing platforms. However, in this article we’ll focus only on Infrastructure-as-a-Service (IaaS) cloud providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). 

We can start with a basic assumption: you don’t need a degree or a computer science or computer engineering degree to learn cloud computing. You can start learning cloud computing from scratch even if you have very basic IT skills. You will just need to learn some of the main concepts, and how those concepts relate to each other. Then get some hands-on practice, especially in fixing problems.

Assumptions about learning cloud computing

1. To learn cloud computing you should be able to code.

FALSE.

To learn cloud computing, you can start using a public or private cloud computing service, even if you are not a software developer. It doesn’t require coding chops to get an account or launch resources in a cloud environment. It will, however, be helpful to think about things in an organized and deliberate way, the way that coders do. And it’s good if you like to figure out what causes problems. There are always problems to be solved.

2. You should have some previous experience in the IT world.

FALSE.

Cloud Computing is a technology used in all industries globally. Understanding it will help everyone, not just technical people. Chances are, you work at a company that is already using cloud infrastructure. It doesn’t matter if you’re completely new to cloud tech, you’ll still be able to learn about the value of it and see the value applied all around you.

3. Cloud computing is only for technical people and developers.

FALSE.

Cloud Computing is changing how companies build and use IT systems, involving all of their software and teams that use it (not just teams that create the tools). Cloud Computing is a topic that managers, marketing people, executives, finance experts, system administrators, and developers must learn about. Of course, this will be with different approaches and specific aspects for the different roles and responsibilities, but that’s the beauty and the opportunity within this field: it touches everyone.

Operating Systems, Virtualization, and Networking

Starting at the beginning: Operating Systems

Since cloud computing is a broad area, to learn Cloud Computing you should have some skills related to basic concepts of an Operating System (OS) — how they work and operate at a high level — e.g. Windows, Linux, and a few basic concepts about them. Really, if you are familiar with using computers for different office duties, that should provide you with enough context. 

Virtualization in Cloud Computing

Once you get your feet wet with operating systems and servers, you’ll see that virtualization technologies play a very big role when we talk about cloud computing: from a die-hard point of view, there is nothing like trying to start your own virtual machine (hint: you can do that with VirtualBox) to understand how a virtualized environment works. 

Virtualization allows you to create virtual environments that have specific amounts of CPU, RAM and disk space assigned and their own installation of an Operating System like Linux or Windows. They share the same physical hardware and all the network equipment but they are virtually separated from the other virtual machines. 

One of the first pioneers in this industry is VMware. Virtualization was a well-known technology before VMware, but they basically changed the landscape by commercializing it as packaged software that is now very common in small, medium, and big sized companies. A key advantage that VMware currently has is that their technology is used across different cloud providers, so while AWS and others fight over the biggest marketshare, VMware can get business in many areas.

Virtualization has introduced an economic and strategic concept called Consolidation. This means that companies around the world, using Virtualization, don’t have to allocate a single, physical server for every type of application or workload they run, but they can share resources across many virtual machines.

Virtualization: Basic Concepts

Virtual Machine (VM): A VM is the basic element in virtualization. Think of it as a custom, ephemeral computer that is created for you. In reality, through the VM tech, a functioning “instance” of a computer has been made and what’s cool is that many VMs can exist on one physical computer. Each virtual machine has its own operating system, CPU, RAM, disk space, and may have a more complicated configuration on the networking side to deal with the complexities that are inherent in virtualization.

Virtualization advantages: As mentioned above, consolidation is the first plus. There is also the option to move VMs among different physical nodes, and flexibility to add new resources to an existing virtual machine thereby making it very modular and changeable for your needs. Another key advantage is economical. You can create VMs of many different sizes from tiny to huge, and a cloud provider can accomplish this with a fixed number of physical resources. A user reaps the benefits of this because they are given many different options with varying costs.

If you want to deepen your understanding of the most important technical advantages of server virtualization, this course on virtualization technologies gives you everything you need to get started.

Hypervisor: This is the name of the “Virtualization Core” that runs all the virtualization machines — it’s the boss of all the VMs on a given machine.  Some examples of hypervisors are VMware, KVM, Xen, or OpenVZ. All the cloud environments use some version of a hypervisor, with an example being Xen, which is used by AWS. You can get in depth info on what a hypervisor is here.

Networking

Once you have basic knowledge of Virtualization Technologies and Operating Systems, you can consider some introductory courses on Networking. Then, you will easily learn cloud computing.

Networking can be a very difficult topic and even those with strong analytical skills typically require time to fully understand it, so don’t lose faith if it all seems like some kind of mystical magic at the beginning — that’s totally normal. 

You can start out by checking out a whole learning path we have that details AWS networking basics, starting with a VPC — a virtual private cloud. To get you started, all you need to think about is that your virtual machine also needs a virtualized communication center. This is the VPC, and within this VPC there are a whole host of configuration options that you can choose to start your deployment and make it secure. Don’t worry too much about understanding all the details right away — some people make whole careers out of networking!

Public vs. Private Cloud Computing

Finally, we want you to have a clear idea of what is meant when you hear discussions about public cloud computing vs. private cloud computing.

Public Cloud: This refers to a publicly accessible infrastructure where you can store data, virtual machines, and any other kind of cloud resources. You can do this autonomously/programmatically, and you don’t have to invest in hardware or infrastructure. You use public clouds with a pay-per-use approach. Think of it like this: you are not buying the car, you are renting it for a specific period of time.

Private Cloud: As a company, you may want all the flexibility and advantages of cloud computing but you may still have your own on-premises data center and infrastructure for security or compliance needs. In a private cloud case, you are responsible for managing the whole infrastructure which can behave in a similar — though at a much smaller scale — way as a large public cloud.

Hybrid Cloud: As the name suggests, this is a combination of the two, and for many groups is driven by business needs. There are cool (and proprietary) services created to connect the public and private clouds directly, such as the aptly named AWS Direct Connect.

In this short lecture, you’ll gain the knowledge you need to understand the differences between these models: Cloud Deployment Models: Public, Private, and Hybrid Clouds.

Hands-on Experience

Research shows that hand-on learning is the best way to learn something. So take some of the ideas we’ve shared above and try them out. We have labs that make it quick and easy for you to get your hands dirty and get reps on real cloud environments.

Check out some quick lab walkthroughs below:

And check out a beginner Hands-on Lab that is designed to help you learn quickly and retain your knowledge:

The post Learn Cloud Computing: Prerequisites appeared first on Cloud Academy.

When we’re using AWS, it’s easy for someone — almost without thinking —  to choose which AMI flavor seems best when spinning up a new EC2 instance. Maybe you’re just doing some quick testing, or maybe you know all you need and your AMI has a relatively recent version of Microsoft SQL Server on it.

However, when you dig a little deeper, you’ll see that the AMIs offer a choice of virtualization type: PV and HVM. What is this and how much do you really need to be concerned with it?

In this article, we’ll cover the basics about AWS AMI Paravirtual and Hardware Virtual Machine. To dive even deeper and learn how to create a customized OS image through an Amazon Machine Image (AMI), check out Cloud Academy’s Create an EBS-Backed Linux AMI Lab. During this lab, you’ll setup a webserver EC2 instance starting from a Linux AMI, and then generate a new AMI.

|

What’s the difference between PV and HVM?

Choosing an AWS AMI virtualization type may not seem critical or relevant at first, but I believe everyone should have at least a basic understanding of how the different virtualization options function.

How many times have you actually thought about which kind of virtualization is best suited to your needs before you select your AWS AMI? Or better: how often have you thought about it, but ignored it and just started working anyway? When you select an AWS AMI to launch an instance you will see something like this:

What are these highlighted terms all about? I’ll explain.

The AWS AMI and the Xen hypervisor

Every AWS AMI uses the Xen hypervisor on bare metal. Xen offers two kinds of virtualization: HVM (Hardware Virtual Machine) and PV (Paravirtualization). But before we discuss these virtualization capabilities, it’s important to understand how Xen architecture works. Below is a high-level representation of Xen components:

Virtual machines (also known as guests) run on top of a hypervisor. The hypervisor takes care of CPU scheduling and memory partitioning, but it is unaware of networking, external storage devices, video, or any other common I/O functions found on a computing system.

These guest VMs can be either HVM or PV.

The AWS AMI and HVM vs. PV

HVM guests are fully virtualized. It means that the VMs running on top of their hypervisors are not aware that they are sharing processing time with other clients on the same hardware. The host should have the capability to emulate underlying hardware for each of its guest machines. This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification — as if it were run on the bare-metal hardware. The advantage of this is that HVMs can use hardware extensions which provide very fast access to underlying hardware on the host system.

Paravirtualization, on the other hand, is a lighter form of virtualization. This technique is fast and provides near native speed in comparison to full virtualization. With Paravirtualization, the guest operating system requires some modification before everything can work. These modifications allow the hypervisor to export a modified version of the underlying hardware to the VMs, allowing them near-native performance. All PV machines running on a hypervisor are basically modified operating systems like Solaris or various Linux distributions.

This is in contrast to HVM, which requires no modifications to the guest OS, and the host OS is completely unaware of the virtualization. This may add to the performance penalty because it places an extra burden on the hypervisor.

Let’s extend this discussion to the AWS AMI. AWS supports Hardware Virtual Machine (HVM) for Windows instances as well as Paravirtualization (PV) for Linux instances. Years ago, AWS would encourage users to use Paravirtualized guest VMs, because they were then considered more efficient than HVM. We’ll talk later about how this has changed, but it’s useful to know the history and the strengths of each type of virtualization.

With that in mind, it’s helpful to take note that there is one major disadvantage with Paravirtualization: You need a region-specific kernel object for each Linux instance. Consider a scenario where you want to recover or build an instance in some other AWS region. In that scenario, you need to find a matching kernel — which can be tedious and complex. Nevertheless, I can’t say that this is the only reason that Amazon now recommends using the HVM virtualization versions of the latest generation of their instances: There are a number of additional recent enhancements in HVM virtualization which have improved its performance greatly.

Here are some key factors that contributed to Hardware Virtual Machine’s closing the performance gap with Paravirtualization:

• Improvements to the Xen Hypervisor.
• Newer generation CPUs with new instruction sets.
• EC2 driver improvements.
• Overall infrastructure changes in AWS.

Consider upgrading if you are using an older instance type.

PV vs HVM choices used to require more research

This table shows which AWS AMI (Amazon Linux) is recommended for each Amazon EC2 instance type:

Amazon currently recommends users to choose HVM instead of PV. Ignoring their advice can have very real consequences. For example, in the AWS Frankfurt region, if you try to select an AWS AMI (Amazon Linux) using PV, you will be greatly restricted in your choice of instance types:

As you can see, the cheapest instance type you can select here is m3.medium. But going with the Amazon Linux AMI on HVM, the cheapest instance type available to you is t2.micro.

As time has shown, it now works this way in all AWS regions, and this should serve to make you aware about the relevance of virtualization type — which we ignore at our own peril.

The PV vs HVM debate is much clearer today

As we’ve seen above, the main difference between PV and HVM AMIs is the way in which they relate to the underlying hardware. However, with the current (as of July 2019) EC2 offerings, HVMs are no longer at a performance disadvantage compared to PV. HVMs can run PV drivers and the correlating EC2 instances have improved such that HVM-based AMIs are faster than PV-based AMIs.

HVM AMIs rule the roost for Windows-based AMIs.

One distinction though: HVM AMIs rule the roost for Windows-based AMIs. PV AMIs are still available for Linux but the same debate carries through — all the newest Linux EC2 instances offer types that run HVM and can be faster, due to specialized hardware access such as enhanced network and GPU access.

Conclusion

Traditionally, Paravirtualized guests performed better with storage and network operations than HVM guests, because they could avoid the overhead of emulating network and disk hardware. This is no longer the case with HVM guests. They must translate these instructions (I/O) every time to effectively emulated hardware. Things have also improved since the introduction of PV drivers for HVM guest. HVM guests will also experience performance advantages in storage and network I/O.

Because Amazon has changed their approach toward the AWS AMI, we have no choice but to address this topic. A few years ago we saw the writing on the wall: It looked like HVM types would completely replace PV types. While that has not completely and utterly happened, it has — in effect — since HVM types are most prevalent among cheap and new instances. So that is why it’s critical that you make informed decisions today.

If you have experience with either AWS AMI instance, share your thoughts in the comments below.

The post AWS AMI Virtualization Types: HVM vs PV (Paravirtual VS Hardware VM) appeared first on Cloud Academy.

Metered, pay-as-you-go Cloud Computing services come in all kinds of flavors. Infrastructure as a Service (IaaS) offerings like AWS allow enterprises to shift their entire operations away from traditional data centers. The downside is that you’ll have to manage networking and provisioning yourself. On the other hand, Platform as a Service (PaaS) providers like Heroku, offer abstracted environments into which developers can simply drop their code and let the platform take care of the provisioning details. You’ll give up some control, but gain simplicity and speed in exchange.

Heroku itself, by the way, is built entirely on AWS cloud servers.

It uses Git (a distributed version control system for code management) to manage application deployments. All you’ll need to do to deploy your application on Heroku is push your Git repository to their servers.

What is Heroku and why are its application deployments so simple

Heroku…

heroku addons:create papertrail

heroku addons:create heroku-postgresql

git push "heroku master"

heroku open

The post What is Heroku? Getting Started with PaaS Development appeared first on Cloud Academy.

Securing egress traffic to the Internet can be tricky because most EC2 instances need outbound access for basic operations such as software patching and accessing AWS services. Additionally, applications often have legitimate needs to send or receive data to and from third-party services or SaaS applications.

Here’s an overview of some different methodologies for securing VPC egress traffic, including their pros and cons. Before we dive in, you might also want to read more about AWS  Transit VPC to familiarize yourself with this service.

Method #1: Egress through your datacenter

Also known as a “trombone” approach, this method routes all VPC egress traffic through your on-prem data center for inspection and filtering using your existing firewall (edge infrastructure) and rules.  Because packets must go on-premises to access the Internet, this approach introduces latency and cost. It’s also incompatible with “cloud-first” initiatives.

Method #2: Allow only trusted egress traffic to leave the VPC

Because the majority of cloud workloads are server applications (i.e., non-user), the list of hosts, protocols, and ports being accessed by each application is typically known in advance. One simple and cost-effective model for securing egress traffic is to allow traffic only to this list of known, trusted sites, which can be vetted by a security team ahead of each release.

This approach effectively stops a hacker or malware from uploading your data to a nefarious site.  It also allows you to keep an eye on where your applications are communicating.

It may seem daunting to do this for all of your applications in the cloud.  However, with a VPC-centric approach, you can do this one application or one VPC at a time.  Furthermore, discovery tools make the job of building the first trusted list easy.

Method #3: AWS Native Services

AWS provides a NAT gateway service and instances to allow your private subnets to reach the Internet.  These services offer some ability filter traffic, but with implementation limited to IP addresses in Network ACL or Security Group. The number of IP addresses is limited so this can become challenging to manage.  Furthermore, you’ll need to query DNS and update the IP address list regularly.

Method #4: Shared-security service VPC

Instead of placing a firewall in each VPC, you could also send all VPC egress traffic to a single shared-security VPC or multiple regional shared-security VPCs. The primary benefit of this approach is that you’ll need fewer firewalls. However, this comes with the disadvantage of making it difficult to filter traffic differently by application or VPC.

A word about Squid and other open source tools

A forward proxy server, such as Squid, can act as an intermediary for requests from internal users and servers, often caching content to speed up subsequent requests. AWS customers often use a VPN or AWS Direct Connect connection to leverage existing corporate proxy server infrastructure, or build a forward proxy farm on AWS using Squid proxy servers with internal Elastic Load Balancing.

While the Squid solution works, it is hard to manage and is limited for cloud VPCs. For starters, there’s limited protocol support. For example, Squid doesn’t support protocols other than HTTP/S. Squid also requires:

• Manual administration of policies, per VPC
• Tedious configuration of each new instance to use Squid

What’s more, new instances can appear without reconfiguring Squid, which presents a big security risk.

Putting it all together

So, after all is said and done, what should you do to filter and secure your VPC egress traffic?

More organizations are choosing a truly cloud-native approach that deploys lightweight, fully automated gateways in your VPCs to control both inbound and outbound traffic.

With a centrally managed, cloud-native approach:

• You can define firewall policies as IP-based rules or as full or wildcard host names from a central web UI or API.
• You’ll avoid having to go to each VPC individually to add, change, or review a policy.
• Your traffic stays local to the VPC and leaves only if allowed by your firewall policies.
• You can use audit logs to prove compliance with PCI, GDPR, and other regulations.

Learn more about how Aviatrix software-defined cloud routing can help you achieve secure VPC egress filtering in AWS.  You can also watch this video or check out this webinar in which we talk about AWS Transit Gateway, a new service to connect VPCs and consolidate edge connections to on-premises networks. 

Understanding VPC traffic and PCI Compliance

Filtering VPC egress traffic is important for compliance with the Payment Card Industry (PCI) requirements for how companies securely collect, store, process, and transmit credit card numbers. Two specific PCI requirements apply to AWS and other public cloud customers:

1.2.1: Restrict inbound and outbound traffic to only that which is necessary for the cardholder data environment, and specifically deny all other traffic.

1.3.4: Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

Solutions for achieving and maintaining PCI compliance that worked in the datacenter don’t necessarily translate to AWS. The two most common mistakes are 1) to use a traditional, non-cloud, firewall in every VPC and 2) to use a centralized firewall.

Traditional firewalls and even their virtual counterparts are a mistake because they can’t be fully automated in an AWS environment. As a result, they slow performance, cause internal friction between your internal teams, and become cost-prohibitive as your EC2 instance charges and firewall license charges grow.

Centralized firewalls are a mistake because they require traffic to be routed to one or several central VPCs, which increases your operations team’s workloads and VPC connection costs, creating a natural chokepoint on your central VPC, limits the size of the central firewall to the size of your instance, and adds unnecessary egress costs to send traffic from the VPCs to the central VPC.

If you want to learn more about cloud networking and VPC design and architecture, we have just the course for you. Join cloud experts Neel Kumar and Mike McLaughin from Aviatrix for a technical chalk talk on how you can solve some of the common issues that can occur when running cloud networking at scale. 

You might also like: 

• Advanced Networking – Specialty Certification Preparation for AWS
• Introduction to AWS Networking
• Virtual Private Cloud – Overview

The post Understanding AWS VPC Egress Filtering Methods appeared first on Cloud Academy.

If you’re a developer, operations engineer, an aspiring security analyst, or just someone who enjoys learning new things, then you’re in the right place!

To follow along, you’ll need the following software installed on your computer:

• Vagrant
• VirtualBox

If you’re new to these tools, VirtualBox is a free virtualization tool, which means that it will run virtual machines. Vagrant is a virtual machine management tool used to start up and configure different operating systems.

Once you have these installed, you’ll need to download the latest copy of the Kali Linux VM for VirtualBox.

Kali Linux is a distribution of Linux specifically used for penetration testing. It contains hundreds of tools used throughout the different phases of a penetration test. It will serve as your arsenal as you learn to hack.

Kali isn’t a prerequisite for hacking. However since it’s preloaded with the most common tools, it’s easier to install the one VM instead of all the other tools.
Once you’ve downloaded Kali, you can start it up and log in. The default username and password are root / toor. Once you’ve logged in, the first thing you should do is change the default password to something more secure.

To do that, open up a terminal window and type passwd . When prompted, type your new password, and then again to confirm.

Next, we’ll use Vagrant to set up the VM that you’ll be practicing your hacking skills on. The cool thing about Vagrant is that it can start up a virtual machine and configure it based on a file named Vagrantfile . The next step is to download the Vagrantfile, as well as some other source code from Github.
Download with git:

$ git clone https://github.com/whelmed/intro_to_web_hacking.git

Download zip file

Once you have the code extracted to its final destination, you’re ready to use Vagrant. On your OS (not Kali), open up a terminal window and change directories into wherever you downloaded the code to and run the vagrant up  command.

Vagrant can take awhile to get everything set up. This is especially true the first time you run it since it will need to download the Ubuntu VM image. Now is probably a good time to go get some coffee, or a beer, depending on the time of day.

Once Vagrant is done, you can test that it’s working by opening a browser on your OS and browsing to this link: http://localhost:8080/login.php.

Another cool thing about Vagrant is that it allows you to bind ports on the VM to ports on your OS. That’s why you can use “localhost” because I’ve bound port 80 on the VM to port 8080 on the host OS in the Vagrantfile.

If it all worked…

If everything worked, you should see a Login window in your browser. If you do, then it’s almost time for the fun to begin.
The web app that you’ll be attacking is called “Damn Vulnerable Web Application.” It’s a web application designed for security professionals to practice web application hacking.

Before switching over to using Kali, you just need one more piece of information: the local IP address of your computer. If you’re on a Mac or Linux system, you can use the ifconfig command. If you’re on Windows, you can use the ipconfig command.

Your local IP address is necessary because Kali needs to be able to access the web application, which is bound to port 8080 on your IP address.

If you have the IP address, now it’s time to switch over to Kali. Start by opening up Firefox and verify that you can access the website. You can access Firefox from the applications menu.

Using Firefox, browse to the web app to make sure you have the correct IP and that everything is connecting correctly from Kali to your host machine.

For me, the URL is http://192.168.1.211:8080/login.php, however, yours is likely to be different. If you’re looking at the login page, then your web hacking lab is ready. Congratulations, you now have your very own lab and the tools to successfully compromise the web application’s host.

I want to give you a quick tour of how this application works, so you will need to log in. While the username and password are freely available in the app documentation, using them kind of defeats the purpose of practicing hacking.

So, I want to start by teaching you to brute force a login page to obtain credentials.

Brute Force

For years, applications have had admin users, often named “admin.” Predictability tends to be good for hacking, so let’s take a shot in the dark and assume there is an admin user, aptly named “admin.”

Start by entering a username of admin, and password of 1234 and submit that, just to see what happens. You’ll see “Login failed” at the bottom of the page. Next, I want you to try the same username and password you just tried 4 or 5 times in a row.

What stands out to you? If you’re new to this, it’s okay to say “nothing,” you’re here to learn after all. What stood out to me is that after getting the password wrong several times, there’s no mechanism in place to either throttle the requests, or display some sort of challenge-response.

This is a prime candidate for a brute force attack. As the name suggests, brute force attacks are as covert as Godzilla casually strolling the streets of Tokyo. However, brute force attacks are common and effective.

Conceptually, a brute force attack works by trying all the possible combinations of a username and password. In reality, there are limitations that make that impractical. You can’t actually try every possible password combination for every user. So, you need to try and hone in on the most salient potential passwords. One method is to use actual passwords from production systems. Because there have been so many data breaches over the years, there are downloadable word lists containing millions of leaked passwords. By using a word list like this, you can quickly try a lot of common passwords before moving on to more complex options.

The tool I’ll use for this is Hydra, which is a relatively easy to use brute force tool that supports multiple protocols. Below is an example of using Hydra’s http-post-form module to post some usernames and passwords to the login page of the web app.

Try it out for yourself, but make sure you change the IP address to use your host’s IP. For me, this takes about 60 seconds to run.

$ hydra -s 8080 -l admin -P /usr/share/wordlists/dirb/small.txt 192.168.1.211 http-post-form "/login.php:username=^USER^&password=^PASS^&Login=Login:S=Location\: index.php:H=Cookie: security=medium;" -f

Command breakdown:

If you ran that command, then know that it didn’t work. That’s because there’s a CSRF token being used on the site. The reason I know this is that I added the -d flag to the command and sifted through some pretty ugly debug text. It’s a common misconception that CSRF tokens have the secondary benefit of preventing brute force attacks. Anecdotally, you might think this supports that claim. However, while a CSRF token is effective at preventing cross-site request forgery, it doesn’t prevent brute force attacks. At best, it forces you to write a bit of code.

An aside on cross-site request forgery

Imagine that your bank’s website allows you to transfer funds from one account to another; that’s a pretty common thing for a bank to support, after all.

The URL to do that might look like this:

https://bank.example.com/transfer/?amount=1000&from=account1&to=8675309

If your “spidey sense” isn’t going off yet, that’s okay. The implied functionality here is that this URL accepts an amount to transfer, the account to transfer from, and the account number to transfer into. This is a useful transfer feature if you’re using it from inside the bank’s website. However, what’s to stop an attacker from editing the URL and getting you to click it?

If you’re already logged in, in theory, the transfer could kick off and send money from your account to the attacker.

This is what CSRF tokens are used to prevent. For each session and/or request, a token is generated and sent along in the HTTP response. The server expects that same token to be passed back with new requests. If you click on the URL outside the context of the bank’s website, the token won’t exist and the request will fail. By the way, this isn’t limited to GET requests, that’s just an easy example.

Back to the beaten path

So, to get a working solution you need to issue a GET request and grab the CSRF token and PHPSESSIONID. Once you have those, you can pass them off to the POST request that Hydra sends.

As a general rule, you shouldn’t run any code that you don’t understand. Make sure you take the time to look over the code. If there’s anything you don’t understand, it’s worth the extra time and effort to look it up.

Here’s a working script to brute force this login:

#!/bin/bash
# This is a modified version of the script found here: https://blog.g0tmi1k.com/dvwa/login/
echo 'Starting bruteforcing...'
ATTACKIP=192.168.1.211
ATTACKPORT=8080
CSRF=$(curl -s -c dvwa.cookie "${ATTACKIP}:${ATTACKPORT}/login.php" | awk -F 'value=' '/user_token/ {print $2}' | cut -d "'" -f2)
SESSIONID=$(grep PHPSESSID dvwa.cookie | awk -F ' ' '{print $7}')
echo "Attacking host: ${ATTACKIP} on port: ${ATTACKPORT}"
echo "Using CSRF Token of: ${CSRF} for session ID: ${SESSIONID}"
hydra -s ${ATTACKPORT} -l admin -P /usr/share/wordlists/rockyou.txt ${ATTACKIP} http-post-form "/login.php:username=^USER^&password=^PASS^&user_token=${CSRF}&Login=Login:S=Location\: index.php:C=fake_cookie:H=Cookie: PHPSESSID=${SESSIONID} security=medium;" -v -f

To run this for yourself, you need to set the IP address, save this, and make it executable. Once you do, run the script and it should print out the password on the screen.

If you’ve successfully run this for yourself, then congratulations! You’ve just brute forced your first application.

Now that you have credentials, you can log into the app with the username “admin” and the password “password.”

The home page is a set of general instructions, and along the side is a navigation bar broken out by the various types of vulnerabilities.

The application is designed with difficulty levels that you can change by clicking on DVWA Security and editing the difficulty in the drop down.

Before setting you loose to practice your ethical hacking skills, I want to talk about the different types of vulnerabilities.

Brute Force

As you’ve already seen, this is an attack where you try multiple possible values until you get the correct one. Humans are awful at remembering passwords, so we opt for something simple, and that makes dictionary attacks effective. When dictionary attacks aren’t successful, there are other options that involve modifying the words in the dictionary with different filters. This might include, for example, replacing certain letters with numbers, adding numbers to the beginning or end, trying different variations of capitalization, etc.

Brute forcing is a “noisy” option because of all the requests made to a service, however, it remains a highly effective attack.

Command Injection

I don’t often see command injection in modern apps, however, it’s always worth knowing about these sorts of things.
Imagine that you wanted to develop a website where people could run DNS queries. You don’t want to re-engineer the wheel, so you create a wrapper around the nslookup command.

The code looks something like this:

shell_exec( 'nslookup  ' . $users_query );

This code runs the nslookup command combined with whatever the user passed in. If the user isn’t being malicious and entered in “cloudacademy.com,” then the command that is run will be:

$ nslookup cloudacademy.com

However, what if the user is malicious and enters something like “cloudacademy.com && id”
The command that will be executed would be:

$ nslookup cloudacademy.com && id

This will run the nslookup command and the id command. Once you can run commands on a system, you’re not far off from gaining root/admin access.

File Inclusion

Unlike command injection, I’ve seen more than a few file inclusion issues in production systems. File inclusion is used to dynamically determine which file should be rendered. It’s common with dynamic languages such as PHP because of the ease of having included files processed by the server. Outside of PHP, the more common use is file inclusion for view templates.

The URL for something like this may be:

http://example.com/somepath/?view=welcome.tmplt

In this example, the view is the file welcome.tmplt . However, if the developers didn’t lock things down, you might be able to do something like:

http://example.com/somepath/?view=../../../etc/passwd

Here, each ../  moves up one directory from the current directory. It may be necessary to try out different paths. If you’re lucky, you’ll be able to read arbitrary files on the system.

File Upload

File uploads are pretty common, and in some cases, they can be a great attack vector. When trying to exploit a vulnerable file upload, the goal is to get the server to run your code. With languages like PHP, if you were to upload a PHP file and have the server process it, it will execute your code. If you can get your code running on a system you’re attacking, you’re well on your way to root/admin access.

With file uploads, you want to figure out what rules the developers might have put in place to prevent you from getting your code onto the system. Are they filtering out certain file extensions? If so, is the filter case sensitive? Are they using a regex that isn’t effective enough? Are they relying on the mime type that’s sent with the POST body? In cloud-native applications, it’s likely that the file being uploaded is stored in a blob storage service such as S3, Azure Storage, or Cloud Storage. If that’s the case, you’ll have to start thinking about how the file is used post upload.

Once you can get your code onto a system, you just need to figure out how to run it.

SQL Injection

Injection attacks are a common problem, and SQL injection is no exception. SQL databases are widely used for many different applications. It’s common for developers to build SQL queries dynamically based on user-supplied data.

Imagine that you want to add search functionality to your new website. You find some samples online and your end result is code that looks something like the following:

$query = "SELECT name, price, description FROM products WHERE name = '$name';";

In this example, the $ name variable is user supplied. Even if a user isn’t being malicious they can’t enter a product with a single quote or it would break that query. However, a malicious user could view data they’re not supposed to such as usernames and password hashes. They could create new records, potentially read arbitrary system files, drop tables, and lots of other disruptive acts.

The difference between SQL injection and blind SQL injection is that blind injection may not provide an indication of what the query might look like.

In the example of the product search, if the products are listed and they have a name, price, and description displayed on the screen, this gives you some clues as to how many columns might be returned and potential names (assuming the developers followed best practices for naming, etc.).

Blind injection doesn’t have any visual indicators to help provide clues, which includes error details. The best you might have is a generic 500 error.

Weak Session IDs

Weak session IDs may not sound all that exciting, however, the session ID is what proves that you are who your username and password claim you are. Once you’ve authenticated, the session ID represents you. Session IDs should be generated randomly so that no one can guess the next session ID.

If you knew what the next session ID for a site would be, then you can become the next person who browses to the site. If that person is logged in since the session ID represents that user, you will have whatever access they have.
Products such as Burp Suite contain tooling that you can use to test the sessions for predictability.

XSS

Cross-site scripting is a very common method where attackers can inject their own scripts into a web page. There are many ways an attacker can use this to their advantage. They could use it to steal session IDs that aren’t HTTP only. They could use it to inject their own functionality into the page, maybe presenting a fake password reset request that sends the current password to them. Or many other wonderfully devious things.

There are different types of XSS attacks. However, the end result is that an attacker gets a legitimate user to run malicious scripts.
For reflected XSS, it’s common that things such as search boxes will take whatever the user entered and display it on the page. If that search happens to be something like

<script>alert('Hello World');</script>

Then a vulnerable site will pop up an alert saying “Hello World.”

Happy Hacking!

I hope this brief intro to setting up a web application hacking lab has been interesting for you.

When you’re ready to stop the VM running the web application, you can run the vagrant halt command from the directory with the Vagrantfile. When you want to start it back up, use vagrant up. And, if you want to free up space from the VM, run the vagrant destroy command.

The next article in this series will show how to exploit SQL injection vulnerabilities with your new hacking lab. If there are other security topics you’d like me to cover, feel free to let me know.

To get a general understanding on Databases, have a look at our two Labs: Create your first Amazon RDS Database or Getting started with Amazon Aurora database engine.

Check out also our collections of labs on Web Applications to get started with web apps.

Happy hacking and thanks for reading!

The post How to Set up a Web Application Hacking Lab appeared first on Cloud Academy.

At the time of writing, Docker had not yet acquired Unikernel Systems, and it’s remarkable that Vineet more or less predicted this acquisition. You’re going to gain a solid understanding of the context of the container, VM, and unikernel discussion, as well as see why it was only logical that Docker would acquire Unikernel Systems. Read on to learn more about the power of unikernels and why they are the way forward for microservices infrastructures!

A Brief History of the Cloud

Cloud computing is increasingly becoming a one-stop solution for large enterprises. The cloud enables large firms to treat all of their computing resources as a utility, thereby making budgeting and forecasting significantly less challenging. Because of the cloud’s rapid growth in the enterprise world, a number of supporting technologies have grown up alongside it.

Traditionally, hypervisor virtualization has allowed customers to multiplex virtual machines on a shared cluster of physical machines. If we look at traditional hypervisor virtualization in Linux, we’ll see an entire operating system running as a guest OS on top of the host OS using a hypervisor like Xen.

The Key Differences between Virtual Machines and Containers

Container virtualization is much lighter than the traditional hypervisors. In this form of virtualization, virtual machines are carved out of host operating systems sharing the same OS kernel —  these carved-out VM’s are referred to as Containers. You can take a quick look at an earlier post, Container Virtualization: what makes it work so well? for a bit of background. 

Containers provide encapsulation for a set of processes to run in isolation from the rest of the system. This means that the applications running inside containers appear to be running on a separate environment or operating system with a dedicated set of resources.

Containers don’t employ the overhead of guest operating systems or of a supporting hypervisor, which means more applications can run on a single host OS compared to a traditional virtualization approach. 

Booting and restarting container applications is faster than using VM’s because the host OS containers are nothing but process. Using containers this way contributes to less downtime and greater productivity.

Because of the container’s lightweight memory footprint, quick boot time, and ease of packaging, many experts believe that containers are the future of virtualization. The above advantages of containers offer an edge over hypervisor virtualization, but that doesn’t mean an end to hypervisor virtualization.

I’ll explain why.

The Rise of Unikernels – A Stripped-Down OS

Unikernels are largely seen as the answer from hypervisor virtualization for the emerging container concept.

Cloud operating systems or Unikernels are lightweight operating systems that are the backbone of a new form of cloud computing where a single hypervisor instance can support a large number of VMs.  These Unikernels are meant to be used within a virtual machine and can’t be run directly on a host OS/machine.

The Constraints of Traditional Virtual Machines

If we look at the traditional architecture of VM’s we see an entire, fully-loaded guest OS running as part of a VM. These operating systems are monolithic even if slimmed down. They are designed to be multi-user, multi-purpose, multi-process, and are extremely complex even for an engineer. They are meant to interact with hardware and thus involve all sorts of complexity needed to support device drivers from various vendors. The complexities listed above will come along if we are running a copy of the operating system even if it is not required.

These traditional systems are meant to interact with hardware, and therefore involve the complexity needed to support device drivers from various vendors. The complexities listed above are dragged along if we are running a copy of an OS — even if it is not required. This means we are bringing a big chunk of dead code with us when it isn’t required in the life-cycle of a Virtual Machine.

Even when the size of a container instance is in hundreds of MBs (if not in GBs) there is much more in the containers than the simple hosted application. This seems like a clumsy way to operate when we are all optimizing everything we can.

The Unikernel Approach: A Leaner System

The primary philosophy behind the unikernel is to tear off all the unnecessary sets of libraries and keep only a selected set of services which the application requires to function. Those libraries are compiled with internal applications, resulting in a complete system we call a unikernel. Unikernels are designed with the understanding that they will not need to run on hardware; consequently, unikernels lack the bloat and complexities of drivers. They aren’t meant to be multi-process or multi-user so they can focus on threads of code which are required to keep your applications running.

The unikernel model removes the need for an entire Operating System altogether, allowing applications to run directly on the hypervisor.

Some of the advantages of using the Unikernels model include:

Advantage #1: Smaller Size
By removing most of the unwanted libraries from operating systems and generating a runtime environment to enable a single application means that a unikernel requires fewer resources. Unikernels carry with them only what is required.

Advantage #2: Enhanced Security
Unikernels provide an excellent security mechanism. They accomplish this by reducing the surface area of a potential attack. Since unikernels compile with only essential elements, they reduce potential approaches for attacking the system. They don’t carry the potential vulnerabilities that would have come with the standard Operating System. There aren’t any shells or utilities to exploit.

Advantage #3: Faster Speed
Unikernels boot fast as they don’t possess the overhead of bringing up unnecessary services that are not required by the compiler’s application.

Advantage #4: Scalability
With reduced guest operating system overhead and smaller memory footprint, unikernels permit a considerably high number of Virtual Machines to run on the hypervisor as compared to traditional VM’s.

Putting It All Together

The cloud is an environment where resources are rented and charged based on usage. The major reasons customers choose cloud computing over the alternatives is the reduced price and the efficient utilization of their underlying resources.
Technologies like Docker and CoreOS have done fantastic work to modernize how we consume infrastructure so that microservices are a reality. These technologies must not rest on their laurels but need to evolve to leverage the power unikernels.

Unikernels will have a major impact on the way we work, now and in the future.

Want to learn more about all this? Check out our Docker and Container Technologies learning path. You’ll learn everything you ever wanted to know about these technologies, including Docker advanced concepts, Ubuntu Core Cloud Computing OS and Snappy Package Manager, and more!

The post Unikernels and the Future of Cloud Computing appeared first on Cloud Academy.

Increasing demand for efficient and secure application portability across environments and operating systems has forced the industry to look for more powerful virtualization designs.
While the hypervisor virtualization model is still used to successfully deploy countless applications across the full range of environments, it does suffer from certain built-in limitations, including…

• Increased overhead of running a fully installed guest operating system.
• Inability to freely allocate resources to processes.
• Significant overhead from calls to the hypervisor from the guest OS can sometimes reduce application performance.

Container virtualization exists largely to address some of these challenges.

What is container virtualization and how does it work differently than hypervisor virtualization?

Container virtualization (often referred as operating system virtualization) is more than just a different kind of hypervisor. Containers use the host operating system as their base, and not the hypervisor.

Rather than virtualizing the hardware (which requires full virtualized operating system images for each guest), containers virtualize the OS itself, sharing the host OS kernel and its resources with both the host and other containers. If you want to deepen your understanding of the pros and cons of server virtualization, here’s a full explanation.

Hypervisor vs. Container virtualization design

Containers provide the bare essentials required for any application to run on a host OS. You could think of them as stripped down Virtual Machines running just enough software to deploy an application.

Many applications – like database servers which work best using block storage – require direct access to hardware resources. Getting that access to disks and network devices through a hypervisor’s hardware emulation will often negatively affect their performance. Container virtualization helps by simply bypassing the emulation layer. As you can see in the above image, containers use the same server hardware and an operating system on top of it, but no hypervisor above that.

What, then, provisions a virtual machine and allocates resources for it? What, in other words, plays the role of the hypervisor for translating VM requests to the underlying hardware?

Technically, the Linux kernel itself has no clue that there are containers living upstairs, but containers can nevertheless share kernel resources through features like Namespaces, cgroups, and chroot. These allow containers to isolate processes, fully manage resources, and ensure appropriate security.

Let’s learn some more about those three tools:

• Namespaces are a way for Linux systems to wrap a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource.

Namespaces, in other words, provide processes with a virtual view of their operating environments. So if your process doesn’t actually require all of the properties of a parent process, and can get by with nothing more than a host name, mount point, network, PID, or its own set of users, then namespaces can get the job done.

If namespaces help processes to get to their environment, chroot can isolate those namespaces from rest of the system and thereby protect against attacks or interference from other containers on the same host. Using namespaces and chroot, you can create a logical container with its own view of the system, but you’ll also need to allocate resources to your new container. This can be done by using cgroups. cgroups (an abbreviation of “control groups”) is a Linux kernel feature that limits, accounts for, and isolates the use of resources like CPU, memory, disk I/O, and network, from of a collection of processes.

It’s these three ingredients that create the magic of container virtualization. The basic architecture is currently used in quite a collection of implementations, the most famous of which is probably Docker.

Now that we’ve got some idea of how they work, let’s review some of the elements that, at least in many scenarios, give the container virtualization its advantage:

• Containers, compared to hypervisor virtualization, are more likely to be secure as, by design, their applications are logically restricted to their own environment.
• Containers provide significantly better performance, as they use native, rather than emulated resources.
• Launching a container is much faster than a virtual machine.
• Containers offer better control on underlying resources.

After this introduction to the technology’s principles, you might like to try Cloud Academy’s Introduction to Virtualization Technologies.

For a full list of all learning material dedicated to containers, browse Cloud Academy’s library. 

And feel free to join in by adding your comments below.

The post Container Virtualization: What Makes It Work So Well? appeared first on Cloud Academy.