Is Azure the flavour of the month, or is Microsoft busy playing catch-up? We’ve been approached by two clients in recent months to help them transition legacy Oracle systems to the Azure platform. We’ve been developing modern tiered database solutions for many years, with Front-end web applications calling Java-based services that use Oracle databases for storage. Just how easy is it to migrate these applications to Azure?
Tiered web applications
We’ve developed many custom web applications using Oracle at their core. We try to avoid embedding database-specific code in front-end JavaScript/HTML, so we work with a tiered architecture.
The front-end
The front-end web application focuses on user interaction, creating responsive, easy-to-use web interfaces. Wherever possible, we shield our web developers from “where” data is stored, and how. When the web interface needs data or wants to save information, it uses simple API calls based on JSON or SOAP.
API (web-services)
We create the JSON/SOAP services that communicate between the database (Oracle, Sybase, MySQL…) and the front-end. These web services are often developed using Java, but sometimes PHP. These services also don’t need to know much more about the database details, just where it can be found. We try and encapsulate the application behaviour using functional API methods. For example, “Save User Profile” or “Read User Profile.” Wherever possible, we avoid the API having to know much about the database structure. It just needs to “know” what information is saved in (following our example) a “User Profile.” Perhaps a user name, phone number, profile photo, and address. So far, so good!
Business Logic (Data model, Stored Procedures, Triggers, and Constraints)
We place the Business Logic in the database, using triggers, constraints, and stored procedures linked to a Data Model which stores the business data. Constraints and Triggers linked to the data model are simple but effective, as they can – returning to our user profile – automatically ensure that a new username is unique. Or check that there is a telephone number for each user. We can accomplish this without the need for our web developers to know anything about the data model or even the type of database. Stored procedures are even more useful, as they can contain intelligent functions and code. So they can perform a sequence of actions on many different database tables if necessary. They are built around the data model. When the data model changes – perhaps in later releases, we can automatically identify inconsistencies, making it very easy to maintain the code.
Easy to maintain
These techniques make it extraordinarily straightforward for BSL to maintain and update our web applications. We can completely change a data model, business rules and stored procedures without any impact on the front-end web application. And our web developers can make interface changes without ever needing to know where or how data is stored. It sometimes brings tears to our eyes when we take over web applications from other developers and find endless “SQL code” buried amongst JavaScript or PHP code. It’s almost impossible to maintain – which means higher costs for the client!
How does this impact Oracle Migration to Azure SQL?
We’re familiar with Oracle SQL programming (PL/SQL), MySQL Stored Procedures (limited in comparison with Oracle), and Azure SQL programming (Transact SQL). We’ve used Transact SQL for many years, even before Microsoft adopted it for their SQL Server. This SQL dialect comes from Sybase – another database we’ve used.
Our chosen architecture means that we can minimise the impact on front-end software. Technically, we can take Oracle out from a web application created by BSL and replace it with MySQL, PostgreSQL, or Azure SQL Server without the need for front-end changes. Naturally, our API developers will need to update the API services so that they “know” about the new location of the data. However, our database libraries can support many different databases from the same code base. So we can quickly migrate from one database system to another, and very few API code changes are needed.
Oracle Migration to Azure SQL
We’re in the middle of a complex migration right now, migrating a critical banking solution from Oracle 12 to Azure. At the end of this migration, their database will no longer run on a server they manage. Instead, their data will reside in an Azure Cloud. As a result, they will reduce their management costs, availability, scalability will improve, and the system will be available for global access by authorised users.
It’s a significant project, as we need to translate over 20,000 lines of PL/SQL code used in more than 200 stored procedures. The applications use data types that don’t exist in SQL Server, which presents a few more challenges for our developers. Still, what’s life without a challenge or two!
The good news: we’re on schedule right now. We expect to complete the project within eight weeks. In our next blog, we’ll tell you more about how we are accomplishing this and which tools we are using to help us.
Next week: Part 2 of this blog.
Get in touch
Have you got plans to migrate your in house system to Azure or any other databases mentioned in this article? Talk to us. Perhaps we can help. You are welcome to contact our relations manager at any time. She can set up an online call.
