I feel like I’m being followed by CenturyLink. I shouldn’t be surprised, they should follow me! 😮
But faux paranoia joking aside, it is interesting to see them snapping up two key players in the Cloud Foundry space that have built .NET support into it at an enterprise level. They’re obviously intent on capturing that market. Now they just need to snag Basho and make those services available without being damaged by windows – in other words, enabling the back end and on premise, but remove the (absurd) notion that it ever is put on Windows Server.
With that I add another congratulations to Teir 3 becoming part of the CenturyLink Family, joining the likes of AppFog and others to help build the next stages of PaaS and cloud technologies combined.
Here’s some of the past news of the AppFog acquisition a few months ago.
So what does this mean for that PaaS Technology? Especially the elements that I’ve lead, built and been a part of in some way or another the past ~2 years? Well, that’s to be seen, but I have several exceptionally good ideas about what will be done. In subsequent weeks I might even add to some thoughts around this as I have in the past. We’ll see if things keep going the way leading developers want them to go or if this is a sign of consolidation and innovation grinding to a crawl.
It is, after all being consolidated into a corporate entity that has historically had no reputation or focus around developing actual new solutions or a culture that can make that happen. I wish the dev teams of Tier 3 and AppFog the best, but CenturyLink better do well by them or it’ll turn into a standard bleed rate of lost brain power and the innovation trust will disappear.
On that note, congratulations to everyone and good luck!
A friend and now coworker of mine, Richard Seroter (@rseroter & Blog) decided to do a comparo. I took the infrastructure based deployment, ala IaaS and he took the platform based deployment, ala PaaS. What we’ve done is taken a somewhat standard ASP.NET MVC with Entity Framework, a SQL Server Database, a UX & UI design and got it running locally. From there we then deployed the same application the two respective ways to deploy the web application to a live environment. He took the Tier 3 PaaS (Iron Foundry + Cloud Foundry for the win) and I took the tried and true method of deploying via Windows 2008 Server instances via the Tier 3 Infrastructure.
Here are the steps I went through and for his steps check out this blog article on the PaaS deployment.
Part #1 – Get Some Servers Setup
First things first, I need two instances. If you’re following along, you can basically use whatever instances or server you want. AWS, Rackspace, or Windows Azure. Based on that there may be a few steps here or there you may need to alter, add or subtract from the process. One for the ASP.NET MVC Application and one for the SQL Server Database. The web app server doesn’t need a ton of resources, so I built it and scaled back RAM and cores to a single core.
In the next step here I’ve selected additional software to be installed on the instance. I’ll need .NET 4.0 so I’ve added this as shown.
After setting up the web server I also setup a database server. For the database server I made sure to allocate some decent resource, setting up 2 cores and 8 GB RAM. I also added the SQL Server installation based on Tier 3’s software packages so it would install automatically when the image is created.
When I setup the SQL Server instance, I used a blue print feature that allows the SQL Server to be installed directly on the image. This of course saved me a lot of time. But it does add to the deployment time of the instance in the cloud.
Part #2 – Setting up Windows Server 2008
The first thing we’ll need to do is log into these machines and configure them, standard infrastructure stuff. Open up the Server Manager (which launches automatically on instances) and verify that we have IIS installed on the web server.
Next log into the database server and verify that the SQL Server is up, running and create the initial database.
Once I had both of the servers up and running I got the application ready to deploy. First a little schema generation to use to deploy the database.
Once the script is generated then transfer it and execute it against the database on the database server.
Always a good thing, even if all green lights are seen on the SQL execution, go in and make sure the tables are all there.
Publish Application (click for full size image)For the web server, as long as IIS is already installed, the setup is fairly easy. First snag the compiled bits that need deployed. We’ll do a direct drop onto the server and get it running.
To get the compiled bits, right click on the Visual Studio Project and select publish. Add a deployment scenario, which I did and set it up to just spit the bits out to a directory. There of course a multiple options at this point to use FTP, WebDav or whatever your choice is. I’m not a particular fan of any of those in particular, they’re all fairly easy.
At this point I actually got hit with the “.NET 4.0 isn’t installed…” which it should have been. I opened up windows update and realized that it had not successfully executed nor had the .NET 4.0 install. This happens with all sorts of instances, regardless of provider, so make sure that the bits we need are installed. Also, with Windows, it’s a really good idea to get windows update turned on.
Back to Deployment
Now that we have the built bits just copy them onto the web application server into the inetpub wwwroot directory. Once you have that copied over you would be able to navigate to the IP of the machine this is setup on. At this time you may also want to setup a cname or a-record to point to the IP, so you can use a friendlier URI.
Now think about what has just gone on for a moment. We had to literally build out machines, add software and more. There were a lot of steps. This takes anywhere from 30 minutes to a few hours of actual work. In a larger business or an enterprise environment it could get extended out even further. Because of the extra complexity it could also end up broken, requiring extra troubleshooting and coding. There could even be a host of odd one off configuration issues with the hosting software itself.
Imagine you wanted to host an ASP.NET, PHP, Ruby on Rails and a Node.js App on the Server. That would be almost impossible. Consider how much extra configuration knowledge an ops person would need to troubleshoot each one of those frameworks. Just sit back and contemplate the complexities involved for a moment. All the complexity goes away with something like Cloud Foundry or Open Shift. With someone managing that system for you, such as us here at Tier 3 with our Web Fabric PaaS, AppFog, Cloud Foundry, or one of the other providers even more of the complexities just disappear.
Time for Summary & Beer
With all the steps and individual tasks needed to get something running in an IaaS Environment, go check out how slick getting something up and running with a PaaS style environment. The juxtaposition between what Richard had to go through versus what I had to go through is pretty significant. Simply put, for the vast majority of all application development can be done against a PaaS Environment and likely should. Digging deeper into the infrastruture elements is rarely needed except in rare scaling circumstances, such as the volume that Facebook, LinkedIn or Netflix deal with. Even then, as has been stated by these companies, they have a PaaS of their own they often build software to. So why not have this ability where you build software?
One of my key metrics, and I’ll be elaborating on this metric more in the future, is when I get to head out of the office for the day, relax, have a beer, and think about what I’ll get to create next. I call this my “Beer Enabler Measure“. PaaS technologies make it much easier for me to get to the relaxing part of my day a lot faster than IaaS technologies, and both of these make sure that I’m not pulling an all nighter without a beer like traditional hosting environments often do.
In the end, sure, infrastructure can be important and can help in transitioning legacy applications into an easier to manage environment. Today though, if you’re doing web application dev of any type, it should be deployed against a PaaS Environment either private or public.
In this session I covered the history, reasons for, and overall impetus of PaaS (Platform as a Service) and why it matters to software developers. The general gist is, it is changing the very way we can and will be doing software development. The change, is absolutely for the better. Developers, consider yourself empowered. Also, more on this in the near future.
There is no logical, easy, or well defined way to test deployments to the cloud. If you’re AWS, Rackspace, Windows Azure, Tier 3, AppFog or any other company – deployment is not simple. A big impetus is to test production, something that absolutely has to be done. The gateways or checks in deploying software; for the underlying infrastructure, the platform, or anything that is geographically dispersed, multi-instance, or similar is very difficult. For software developers, devops, and the like, we want this to be better. We all brainstormed a bit around this and the resounding sentiment was, “damn, this is hard, yet so powerful and enabling that we have to figure out better ways to test and do deployments into cloud environments”
Chaos Monkey must bet let loose on the WORLD!! See below:
@iC@adron it’s on the way, actively being cleaned up for github
Adrian Cockroft RULZ! Thx Adrian, we’ll all keep an eye out for that! 🙂
One of the other things that was brought up was the endless options, and thus complexity, around the data story these days. This translates to, how do we simplify deployment of relational, document, object, key value or other types of databases? Each needs a particular type of default deployment. How do we as developers create a better model to get our data repositories of choice up and live. With Cloud Foundry the data deployments are a single node, which isn’t really useful for things like Riak, Mongo, Couch or databases that need to start with three or more nodes. It’s ok for relational databases, but it is very common to need that hot swappable database running somewhere. These are all questions that need answered to make the data story of PaaS technologies more palatable.
Monitoring and intelligent systems. Some suggestions around monitoring, which came from the question of how to test a deployed system before and after deployment, where pretty solid. Nodes need to be intelligent enough to be able to identify they’re live, active, and doing X, Y or Z. Controllers need to understand and know how to interact with these nodes. The back and forth is somewhat complex, but I can imagine just like with Cloud Foundry, they’re is a viable and simple solution among all of this with the appropriate abstractions and build out of systems.
That’s my summary. I had a blast, got to see a lot of people I know and meet a lot of new people I didn’t know. I always love being able to catch up and really expand on what our efforts are individually and collectively as a development community. Great fun, until next time, cheers!
I’m putting together a pretty sweet little application. It does some basic things that are slowly but surely expanding to cover some interesting distributed cloud computing business cases. But today I’m going to dive into my Raven DB experience. The idea is that Raven DB will act as the data repository for a set of API web services (that seems kind of obvious, I state the obvious sometimes).
The first thing we need is a server instance to get our initial node up and running. You can use whatever service, virtualization tools, or a physical server if you want. I’m going to use Tier 3’s Services in my example, so just extrapolate for your own situation.
First I’ve logged in to the Tier 3 Control Site and am going to create a server instance.
Building the Tier 3 Node for Raven DB
Next step is to assign resources. Since this is just a single Raven DB node, and I won’t have it under heavy load, I’ve minimized the resources. This is more of a developers install, but it could easily be a production deploy, just allocate more resources as needed. Also note, I’ve added 50 GB of storage to this particular instance.
Now that we’ve set these, click next and on the next screen click on server task. Here add the public IP option and select the following services to open their ports.
The task will display once added as an item on the create server view. Once that is done, click create server so the server build out will start.
Now log in with RDP to start setting up the server in preparation of loading Raven DB. The first thing you’ll want to do is go ahead and get Windows Update turned on. My preference is to just turn it on and get every update that is available. Once that is done, make sure to get the latest .NET 4 download from Windows Update too.
Once all of the updates are finished and .NET 4 is installed we’ll get down to the business of getting Raven DB Installed. In this specific example I’ll be installing the Raven DB as a windows service, it however can be installed under IIS so there are many other options depending on how you need it installed.
Installing Raven DB
To get the software to install, navigate over to the Raven DB site at http://ravendb.net/ from the new instance we’ve just spun up. Click on the Download button and you’ll find the latest build over on the right hand side. Click to download the latest software package to a preferred location on the system.
Once you’ve downloaded it (I’ve put my download in the root R:\ partition I created) unzip it into a directory (I’ve just unzipped it here into R:\ to make the paths easy to find, feel free to put it anywhere you would prefer. In our Tier 3 environment the R drive is on a higher speed, thus higher IOP drive system, thus the abilities exceed your standard EBS/AMI or S3 style storage mechanisms.).
At this point, open a command prompt to install Raven DB as a service. Navigate to the drive and folder location you’ve saved the file to. Below I displayed a list of the folder and files in the structure.
Once you’re in the path of the Raven.Server.exe file then run a slash install on it to get a Windows Service of the Raven DB running.
To verify that it is up and running (which if you’ve gotten these results, you can rest assured it is, but I always like to just see the services icon) check out the services MMC.
There it is running…
Now, you’re not complete yet. There are a few other things you may want to take note of to be sure you’re up and running in every way you need to be.
The management and http transport for Raven DB is done on port 8080. So you’ll have to open that port if you want to connect to the services of the database externally. On windows, open up the Windows Firewall. Right click on the Inbound Rules and click Add Rule.
Enter a name and description on the next wizard dialog screen and click on Finish.
Now if you navigate to the IP of the instance with port 8080 you’ll be able to load the management portal for Raven DB and verify it is running and you have remote access.
At this point, if you’d like more evidence of success, click on the “Create Sample Data” button and the management screen will generate some data.
At this point you have a live Raven DB instance up and running in Tier 3. Next step is to break out and add nodes for better data integrity, etc.
In this write up I’ve shown a short how-to on installing and getting Raven DB ready for use on Windows Server 2008 in Tier 3’s Enterprise Cloud environment. In the very near future I’ll broach the topics of big data with Raven DB, and other databases like Riak and their usage in a cloud environment like Tier 3. Thanks for reading, cheers!
I have jumped head first into CloudFoundry over the last few weeks. In doing so I’ve started working with AppFog, IronFoundry, VMware and other devops tools. There are several avenues I’m taking to get more familiar with CloudFoundry based PaaS technology. Here’s a short review:
Currently I’ve been working up some Enterprise Prototypes using the IronFoundry Technology. The idea is to provide a seamless deployment option for Enterprises that may have a very mixed environment of public and private computing options, virtual and non-virtualized environments, and any array of other capabilities. I’ve also been toying around with Windows 2008 Server Core, which I’ll have more about shortly.
AppFog provides a public facing PaaS supporting PHP, Ruby on Rails, Java, MongoDB and a lot of other packages. They’re currently in beta right now, which I was fortunate enough to snag access to, but I’m sure the covers will come off soon enough! The underlying technology is built on CloudFoundry, providing a robust, scalable, and capable infrastructure connection to provide PaaS on.
In addition to AppFog there is the CloudFoundry.com offering, which I’ve tested out a little bit, but mostly focused on AppFog and on building out…
Private Cloud Capabilities w/ Public Cloud Style Infrastructure
I’ve built out some images to test out how CloudFoundry and IronFoundry works. I did pull down the provided virtual machines but I’m also building out my own to understand it better. The Ruby + C# that I’ve seen from the VMware crew & Tier 3 team has been great so far (I always dig reading some solid code).