Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘paas

Moving on to 64-Bit

with 11 comments

Introduction

Long ago we contended with the migration of our Windows programs from 16-Bit to 32-Bit. This was catalyzed by the release of Windows 95 which was the first popular desktop version of Windows at this bitness. At that time everyone jumped on 32-bits because under 16-bits you could only address 64K of RAM and this just wasn’t enough. With 32-bits suddenly we could address 2 gigabytes of RAM. Plus the Windows 32-Bit API fixed many problems in the Windows API and allowed true and proper multi-tasking. At this point Windows had become a true OS. Perhaps we weren’t really happy with Windows until Windows XP, but at least it was starting to be powerful enough for typical usage.

winx64_teaser_0

We’ve started seeing 64-Bit versions of Windows for a while now, but it was really with Windows 7 and Windows Server 2008 that these were finally working well enough to be compelling. Plus now it is quite inexpensive to purchase more the 2Gig or RAM and if you don’t have a 64-Bit operating system then all that extra RAM isn’t going to get used. The nice thing about these 64-Bit versions of Windows is that they run 32-Bit Windows programs extremely well and then each separate 32-Bit program can get up to 2Gig of RAM and you can run a whole bunch of these.

We haven’t seen the same mad rush to 64-Bit applications, like we saw a big rush to 32-bit applications. This is because for most purposes 32-bits is just fine and 2Gig of addressable RAM is plenty. Another reason is that there is no “thunking” mechanism to allow 64-Bit processes call 32-Bit DLLs or vice versa. So your application has to be 100% 64Bit or 100% 32Bit. This then means you need to move your application along with all libraries, add-ons and anything else all to 64-Bit. This can be a logistical problem and is the main reason people still run 32-Bit Internet Explorer and Office.

So what sort of programs benefit from 64 bits? The main ones are server processes like SQL Server. When running on a server with say 64Gig RAM, why shouldn’t SQL Server use 32Gig for cache? And then to efficiently access this it needs to be 64-Bit. Similarly programs like Adobe Photoshop need to handle huge amounts of RAM to do their job and are far more efficient at this as 64 Bit programs.

But what about business applications like Sage 300 ERP? Does it make sense for this to be 64 Bits? For the regular Windows Desktop and for regular data entry screens it doesn’t make any sense. The heavy lifting is done by SQL Server and communicating with 64-Bit SQL server over the network is no problem. For individual screens, they don’t need anywhere near 2Gig or RAM, so they are fine as 32-Bit programs. Then there is no problem with customizations and integrations to other programs, it all continues to work.

The difference is once we start accessing our business logic from a web server. Then we might want hundreds of users using our business logic. Web servers typically run as one process (i.e. an IIS application pool or a Java Tomcat Server) and then all the users run as separate threads inside this process. So if we want to fully exploit the power of a powerful server with lots of RAM and many processors then we need to be a 64-Bit program.

The 64 Bit C/C++ Compiler

For the most part Microsoft left the command line arguments and functioning of the C/C++ compiler the same between 32-Bit and 64-Bit programs. You only need to invoke a different one depending on if you want to compile 32 or 64 bit. If you want to compile for 32 Bit then set your path to “C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin” and if you want to compile for 64 Bit then set your PATH to “C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64”. You also need to ensure you keep your 32-Bit libraries separate from your 64-Bit libraries.

If you are building directly from Visual Studio or using MSBuild then you need to either add or change your configuration to target x64. All in all rather easy.

When you build 32-Bit you can #ifdef using WIN32. Be careful in 64 Bit because both WIN32 and WIN64 are defined. This is because most programs mean not WIN32 to mean WIN16, so strangely this leads to more correct behavior, which you do need to be aware of it.

Building C/C++ Programs

The big differences going to 64 Bit are that pointers are now 64 Bits, you can more easily use 64 Bit integers and structures are now aligned on 8 byte boundaries. All the regular C data types like int and long are still 32 bits in size. So let’s look at some of the things that need dealing with and some of the things that don’t.

When we migrated from 16-Bits to 32-Bits the big killer was the changes to the Windows Proc. This is the callback function that gets called for each Windows or Dialog box message. In 32 Bits Microsoft changed which parameter did what and it caused havoc. They introduced macros to help and everyone had to adopt these macros and then do lots of debugging. I suppose with these macros in place, this should be easier this time around, but actually I don’t care! For this port to 64 Bits I only want to port the API to be used by server processes like web servers. I don’t actually want to port any C based UIs to 64 Bits, so I don’t really care if these Windows Procs work or not. For now I’m just ignoring them entirely. This also gives us a chance to produce a version of System Manager with far fewer DLLs that can easily be installed in a PaaS environment where you need to quickly install your software as a VM boots.

Generally I found that porting to 64 Bit is helped by a good debugger so once you get test programs working 64 Bits its fairly easy to sort out what is going on. Plus when you google on the various errors or functions that are failing, you get lots of good hits.

Some things that cause problems are:

  • Since pointers (and hence handles) are 64-Bit, you cannot store them in longs or DWORDS. The compiler gives you warning about doing this and at some point these will need to be fixed. Superficially these may work, since most of these pointers seem to have the high 32-bits set to 0 on my computer. But you are living on borrowed time.
  • Similarly some lengths like SQLLEN in ODBC are now 64-Bit, this way you can have more than 2Gig records in a SQL table. Basically you have to be careful and use the correct types or you will get many compiler warnings and will overflow if you ever get this many records. Worse if you pass a pointer to an int type then it will overrun and corrupt something else or GPF.
  • 32-Bit windows was fairly efficient, so even though it had a structure packing of 4, most Windows related structures had no empty space, so you didn’t have problems if say you compiled with the –Zp option (which sets structure packing to 1). However in 64 Bits these Windows structures are sets of ints and longs and the structure packing of 8 leaves lots of empty space and is incompatible with –Zp. I ran into problems here with Windows security descriptors; that basically all the functions and macros for dealing with these don’t work under a different packing option.
  • Beware that registry entries are no longer under Wow6432Node, you get to use the real entries now. Also make sure you use the 64-Bit versions of ODBC and RegSvr32.exe. A lot of EXEs that got 32 tacked on the end, now have 64 bit versions, but remain with the same file name.
  • The 64-Bit compiler doesn’t support the _asm keyword, so no inline assembler. We only had a few instances of this that were cut/paste from MSDN for diagnostics like reporting a stack trace when something when wrong.

Summary

Moving to 64 Bits isn’t for everything; however, for running in the context of a Web Server it makes a lot of sense. I think the migration from 32 Bit to 64 Bit is much easier than the migration from 16 Bit to 32 Bit was. The tools are much better these days and the tools behave the same way in 32 or 64 bits. Plus all the work we did to use macros and make things type safe when we went from 16 Bits to 32 Bits now helps with the transition to 64 Bits. The only hard part is that you need to go all 64 Bit and can’t just call 32 Bit DLLs. Now I just wonder how long before we need to re-compile for 128 Bits.

Advertisements

Written by smist08

October 5, 2013 at 3:39 pm

Azure and PaaS Versus IaaS

with 9 comments

Introduction

Sage 300 ERP has had a cloud version for over ten years now with Sage 300 Online. I blogged a bit about how this offering works here. Basically we offer our on-premise product in the cloud relying on Citrix and Terminal Services technologies to host and allow access. You are basically running your on-premise Windows desktop ERP application in the cloud. The only thing required on the local computer to access the software is the Citrix client component which is available for Window, Mac, iPad, etc. We are currently hosting this in Sage’s Atlanta data center.

We are now looking to produce the next generation of this cloud offering and we are looking to host it in Microsoft Azure rather than our own data center. There are quite a lot of reasons for this, like being able to deploy globally to various Azure datacenters or to take advantage of the Microsoft network which provides quite low latency access to these data centers. But the Azure feature we are going to explore in this blog posting is what does Azure PaaS give us over an IaaS offering? What are the differences and what are the considerations?

IaaS

IaaS stands for Infrastructure as a Service. In this model the provider, typically someone like AWS or Rackspace, provides all the hardware, storage and networking equipment. Then they give you the ability to create virtual machines in this environment (often providing some starting templates of typical servers). It is then up to you to install everything you need to run on these virtual machines and to maintain them fully going forwards, ensuring all patches are installed, upgrading to new versions of the operating system, etc. If you need a database server then it’s up to you to buy and install that database server on one of your virtual machines and it is up to you to maintain this server, back it up, provide geographic redundancy and anything else that is required to keep the data safe.

PaaS

PaaS stands for Platform as a Service. The goal of PaaS is to build on IaaS to have the vendor also take care of maintaining the operating system and the database server. So you don’t need to worry about patches, backing things up and various other chores. Microsoft Azure is an example of a PaaS offering (although they are getting into offering IaaS as well). Below is a diagram showing how the layers are often separated. This also gives the vendor the opportunity to provide more advanced monitoring and management tools for the platforms they are supporting.

Cloud_computing_layers

Complexities of PaaS

That all sounds good but how do you separate out the maintenance of the operating system from the maintenance of the application? Generally the way this is done is that whenever you start a VM you start with a fresh copy of the operating system which is then guaranteed to be at the most recent patch level. In the IaaS model you start with the operating system template once, then everything that happens to that image is stored to disk and if the image is stopped and started you continue from where you left off. In the PaaS model if your image is stopped and started, then it is restarted with a fresh image of the operating system and you need to install all your software before it can start processing.

This is why most PaaS systems tend to be very specialized in the type of applications they can run. Azure is built around running ASP.Net applications. Microsoft provides support in Azure and .Net to easily deploy your ASP.Net application to a new operating system image as it starts up. Similarly Ruby on Rails PaaS vendors provide support for installing the Rails application on their new image as it starts.

But doesn’t that mean you have to transfer huge amounts of files to the environment every time a VM starts? Well actually no. Azure provides a number of non-VM storage mechanisms for storing files in the environment. So for instance you can use blob storage or one of the other storage mechanisms to hold all your files and data. Then the scripts that start the VM would just attach these to the VM when it starts, or your program knows how to use the Azure SDK to connect to these when it runs.

PaaS databases are bit easier, since you just create and access your SQL Server databases in Azure SQL just like you would in a regular SQL Server, you just need to know the right information for the connection string to the Azure SQL server. But there are still issues to be aware of. For instance when you create your own set of VMs to make a production system, you can specify them in a VM group and ensure they all run in the same area of the Azure data center. This then ensures any latency of communication between these VMs is very low. But when you switch to the PaaS database server, all the servers that comprise, say Azure SQL all run together in another area of the data center and the latency from your server group to this server group is a bit higher than communications within your own group. Further you are then sharing these servers with other unrelated applications using these servers, so you are relying on the vendor to provide sufficient processing power to keep everything performant. But the best thing about PaaS databases is that you don’t need to worry about tuning the server or backing up all the data.

azure1

Moving Sage 300 ERP to PaaS

But Sage 300 ERP is not an ASP.Net application. So how can we even run in this environment? Fortunately, Microsoft provides both IaaS and PaaS services in the Azure environment. This means we can move our current Sage 300 ERP cloud implementation from our Atlanta datacenter to Azure by using the Azure IaaS infrastructure. We can then start to take advantage of various PaaS services one by one.

The whole Azure infrastructure provides a very rich API which allows you to use PowerShell scripts to control what is going on. Hence the ASP.Net support is really a set of scripts developed to handle typical deployments that is built into the Azure/Visual Studio SDK. From Sage 300 ERP we are developing similar scripts to create and control a Sage 300 ERP deployment. This way we can incorporate PaaS building block into our system. So we can have scripts to start and configure the whole system, scripts to add applications servers and so forth. We can even integrate these into standard DevOps tools such as RightScale or Chef.

Leveraging Azure SQL is perhaps a bit easier since you can use the same access technology we currently use. We have to add a bit of code to our database driver to handle some cases that can happen in the Azure environment but generally using Azure SQL is very similar to using regular SQL.

The system that makes up Sage 300 ERP cloud consists of quite a few VMs all performing various tasks. Switching some of these to PaaS based servers is very straight forward, so we can do this right away. For our application servers that have full Sage 300 ERP installed, we will continue to maintain these as IaaS for the foreseeable future since right now the overhead in installing full Sage 300 ERP is a bit high. But there are features coming in the Azure roadmap which will over time let us migrate these to PaaS as well. To some degree PaaS is still in its early stages and new services are regularly being rolled out and we can take advantage of these new services as they appear.

In our Atlanta data center we operate Sage 300 Cloud on a fixed set of servers that we purchased and as the usage grows we buy another server now and again. With a managed service like Azure we are paying for our infrastructure on a usage basis. However the system is elastic, meaning that we only need to run as many application servers as we need to handle the current load. So if usage is low during the weekend then we can shut down some application servers and save some money. Similarly if we get a big spike in usage we can easily add as many application servers as we need instantly to handle the load (perhaps at year end). Again basically we control all of this with a number of PowerShell Scripts.

Summary

Microsoft Azure is a very rich cloud environment. It provides us with a lot of benefits to help us beef up our Sage 300 ERP Cloud offering. But with the richness, there is quite a bit of work creating scripts to take advantage of it, tuning our application for this environment, as well as a learning curve learning the best ways to leverage all these new PaaS features.

Written by smist08

January 13, 2013 at 12:59 am