This is my second post on LXD containers. Sometimes, using a container is a cleaner way to install and use applications for a number of reasons:

• You can install packages from any version of any distribution. That means, even if you are using an LTS release of Ubuntu like me, you don't necessarily have to stick to an older version of a package. Or if some package is only supported on rpm based distributions, you don't need to worry about it.
• You can go ahead and completely uninstall/reinstall it at any time without worrying about residual files or configurations.
• You can roll back to a previous state in no time if something goes wrong unexpectedly (lxd snapshots!)
• And then there is the security perspective also (lxd containers are secure by nature).

Last weekend I tried running mysql database from a local container and connect to it from my local system. Here's how:

Lately I have been playing around with LXD containers and I must say that I am quite impressed with it. LXD is the virtualization technology that can be used to run a Linux container on a Linux host using the same kernel as the host.

Well, it's a little difficult to grab the idea at first. Unless of course you interacted with it before. You can think of it as a virtual machine that you run using VirtualBox or VMWare on your Linux or Windows host machine but the difference is that when you run a virtual machine, you are running a separate kernel inside the virtual machine but in this case, you are fooling the guest OS running inside the LXD container into thinking that it's running its own kernel whereas it's just using the same kernel running on the host OS. And the result is that you get an isolated container with a much smaller memory footprint and little overhead compared to a full blown virtual machine.

In my last post, I discussed about how I created my first Amazon EC2 instance and ran our Java web server on it. One of the most important things that I have realized over the years is that if you work with a small group of developers, you ought to think about automating certain jobs like testing, deployment, setting up server etc. So that you can concentrate on the real work rather than spending valuable time in doing repetitive tasks. The benefit against spending extra time in writing scripts may not be prominent at first, but over time you will realize the gain in terms of person hours and headaches saved because of the automated scripts.

Today I will be writing about setting up an Ubuntu instance on the Amazon AWS cloud and running a Java web application on it. We are working on a hobby project that has its back-end written in Java. The app back-end was first hosted on Heroku but due to some issues, we decided to move it to Amazon AWS. I was given the responsibility to set up our server. This was the first time I had an opportunity to work with Amazon AWS. But it turned out to be quite fun.

I have been working on a home project these days for which I needed to use a Javascript framework on the UI. But to select a JS framework is a difficult task because there are a overwhelmingly lot to choose from. And each of those has its own strengths and flaws. Still after considering a few of them, I finally chose React. The reasons why I selected React are a) it's more Javascript-centric  than some of its close competitors which means, you write your app in JS with pieces of HTML embedded inside JS and b) it uses the Node.js and the npm ecosystem, so it's easier to grasp for somebody with prior Node experience. So I decided to learn React.js.