In the previous post I’ve explained in short what OpenShift is about and how you can use it. In this post I’ll go a bit further in how to use the OpenShift origin framework in a private pass environment. I’ll do this by creating an application based on the “Do it yourself” cartridge. Read more
In this post I’ll try to explain why everyone should start using OpenShift.
1. What it is?
The paas platform OpenShift is a free and opensource platform from RedHat. With free, meaning actually that you get 3 gears for free. On those nodes (see it as virtual servers), you can do almost everything you want. From running a JBoss Application server, up till a php application or do something with MongoDB.
The fact that it is open source makes it even more nice. You can simply download the paas platform and install it in your own small datacenter, taking advantage of all the features the online platform gives you. Simply clicking on the image below will bring you to the download page to install it in your own datacenter.
Xebia’s expertise with middleware and application deployment automation led to the wish to† explore new tools handling these area’s.
Along came VMware’s Application Director 1.0 beta and later GA, and together with VMware Netherlands we built a demo environment at Xebia.
The setup did not go real smooth, mainly because we had some infra setup troubles and the interfacing between software components did not work directly.
After all was working, I compared the vApp director 1.0 with Xebialabs’ DeployIt deployment tool.
Conclusion: vApp director 1.0 is nice, but more operations/infra oriented than developer oriented. With DeployIt, when parts of the deployment (say, only a war & datasource) is changed between deployments, only those steps are done in correct order. With vApp dir, you have to script this out, or deploy everything from scratch, which takes a long time. On the other hand, DeployIt cannot create VM’s by itself.
The following story I find really interesting.
Bhaskar Sunkara, VP Product Experience at AppDynamics, presents “Performance on Amazon AWS”.
Among other things, AppDynamics is known to be used by NetFlix to monitor thousands of JVMs on Amazon AWS.
The presentation tells you about how Netflix partnered with App Dynamics to monitor their systems in a (more than) dynamic cloud infrastructure by AWS.
A large part of the presentation explains about what the important design principles are to be aware of when developing for the cloud.
Main message: machines will come and go, systems will go down. Application availability is in the hands of the developer. Develop for availability.
Today I had an interesting error when powering on a virtual machine in VMware Workstation 9 on my Windows 7 host.
When powering on the virtual machine I got the message ‚ÄúThe VMware Authorization Service is not running‚ÄĚ. Read more
At XebiaLabs, many of the questions we get about our enterprise deployment automation solution Deployit are from users looking for automated deployment as a prerequisite for Continuous Delivery. Often, this the result of initiatives to extend existing Continuous Integration tooling to support application deployments.
Increasing the frequency of whole-application testing, decreasing time-to-production and delivering greater business value faster and more regularly are goals we definitely share, and in this post we’d like to pass on some key experiences and lessons from working together with our users to help them realize Continuous Delivery.
After being derided as “unpure” by cloud enthusiast when the idea was first presented, we can now safely say that the hybrid cloud is here to stay. The mix of dynamic requirements within the enterprise related to government/industry regulations, security and performance require a more flexible environment than the public cloud can offer. So what does a hybrid cloud actually mean? A hybrid cloud is a composition of a private cloud and public cloud. There are two types of scaling patterns when using a hybrid cloud: vertical and horizontal.
A vertical scaling pattern is the better-known scenario. This pattern spreads different components of one application across different clouds. An example of this would be where one part of an application, typically the data, is kept private, while another part is run in the cloud, such as the web front end or calculations being made on the data.
A horizontal hybrid cloud scaling pattern, on the other hand, spreads different instances of applications across different clouds. In this scenario, enterprises develop their own applications and run them in multiple environments, some on-prem, some in the cloud. Developers run it in a test environment, testers test it in a QA environment, and users access the version that has been deployed to the production environment. Each of these environments can be in the cloud or on-prem depending on the security, performance, flexibility and scalability requirements of that environment.
This is a true story of a company. At the first of January this year ago this company was a great idea and a few pictures. It had been like that for a while. At the first of April it was a company with a production website doing actual business with actual clients. The 12 weeks in between that have been awesome, nerve-wrecking and scary at the same time. We’ve had to let go of some really cool features and we’ve found out things about the business case that we definitely didn’t know when we said we could build it in such a short time. At the beginning of the project I invented the term “Oh shit erlebnis” and I’ve had a few since then.
Because we were working in short iterations (1 week Sprints), we had awesome focus and we could deal with most discrepancies between dreams and reality quickly.
We all know the rule in some form or another: three times and you automate. And although I try to apply it, I find myself repeating some things with every new project, like creating a new CI server.
One solution would be to have a centralized server for all your projects, but customers are mostly not willing to depend on services outside of their network, which means you are often stuck with having to create a local solution for each project.
Having done this three times, I decided to start a repository to store scripts to automate development machine setup. One command to get you a fully functional system you only need to tweak to suit your needs. This blog will show you how to quickly set up a Jenkins server on a local virtual machine.
2011 has been an interesting year for cloud computing. Traditionally, cloud computing can be divided into three categories:
While SaaS has been around for some time (Salesforce.com started in 1999!), we are seeing an increase in adoption of IaaS and some heavy development in the PaaS world.
Now that 2011 is coming to an end, this is also the time for lists. So here are my 3 top 3‚Äôs of cloud computing.