Over the years businesses in the SME and Enterprise segment build applications and deployed prepackaged applications on multi-modal commercial RDBMS systems such as My SQL sever, Oracle and DB2. These DBMS was first designed in the 70s when optimal utilisation of memory and compute resources was critical for performance of application transactions and query processing of various decision support systems.
Since then these RDBMS have evolved into a common IT staple for managing clusters of structured and unstructured data in business environment of any sector. In fact, they have a strong influence on how applications were designed and built in the past.
Most RDBMS vendors also built prepackaged applications that resided on their RDBMS systems further locking customers into their environment, though it must be noted that many of these applications were the foundation for business process automation and integrations that drove workforce productivity.
The complexities of running open-source databases in house..
Growing data and high cost
While many of these solution resulted in high performing systems of the time (pre cloud era) over the years businesses started to incur high cost to maintain the exponentially growing organisational data due to automation, mobility, web and sensors. These included DB licenses, ETL related tools and software licenses, storage, compute, and increasing number of human resources to administer performance of the data layer empowering various business processes.
Migration to open-source databases..
In much recent times, businesses have been experimenting with open-source databases for some applications where data growth is significant in order to cut database licensing cost. But this attempt resulted in various problems such as limited features (or features are not as robust as commercial systems), steep learning curve, expensive support and constant config, bug fixing, patching and performance tuning activities. While businesses were able to escape the licensing cost, maintaining a dedicated database team that keeps the open-source databases at an optimal level was a time consuming and arduous effort on the organisation's part.
Scaling based on forecast demand
To add salt to the pain, all of these cost are incurred based on forecasted demand as most businesses are scaling systems in a conventional environment (without cloud capabilities) which means cost is incurred way before the business hits the projected demand. Though this is a universal problem with most conventional IT architectures that lacks cloud capabilities to instantly provision, scale, update, patch and de-provision based on internal demand.
New cloud based applications and microservices...
As we enter the cloud era, application architectures started to take effect of the SOA capabilities of cloud, with high levels of abstraction in every layer (e.g infrastructure, data, intergration and application).
A polyglot architecture where developers can take advantage of the best DBMS, programming language and other ready cloud services including AI, IOT, and Bigdata that accelerates application delivery, begin to take center stage. Apart from SQL type of DBMS, no SQL requirements to support other data types such as value store, document, graph, time series and in-memory DBMS started to emerge as demand rises to 40%. All of a sudden, purpose built DBMS were starting to look much appealing to developer communities every where as opposed to multi models.
Choosing to build such an applications on commercial database can make projects less viable in terms of both cost and feature sets required for a cloud environment where service orientation and scaling instantaneously based on demand is of high importance.
Why cloud based open-source databases are a good option?
Thanks to increasing popularity of public clouds, open-source databases today are mature enough in terms of features and support for wider adoption in businesses including large enterprises.
Overcome management constraints posed by on premise deployments...
It's common to find MySQL, PosgreSQL, MariaDB, MongoDB and countless others in organisations' on premise environment, underpinning many critical business application both prepackaged and customised, but then those implementations are plagued with similar issues surrounding commercial databases such as scalability, availability, security and high operational cost to keep it updated and running.
Cloud providers' DBPaas services eliminates this issue by removing day to day operational complexities from businesses that just want to use the services to build various business solutions to increase quality of engagement with existing and new types of audiences.
Wider adoption and value extension is now possible....
With database administrative task out of the equation, tech teams can now focus on migrating more applications on open-source databases for better value and standardisations within the organisations.
High priority business requirements can be addressed much faster than before with available team and funds, curbing the need for any shadow IT by LOBs.
Refactor apps for the cloud..
Another indirect benefit of this exercise is to modernise legacy applications sitting on premise environments. The migration process is an excellent opportunity to learn more on what pure cloud based databases can do for some applications.
Many cloud databases such as Aurora, Dynamodb, Azure, Google Cloud Bigtable, Google Cloud Datastore, Aspara and DocumentDB are quickly maturing in feature sets and support for other open-source database engines especially MySQL, PostgreSQL, MariaDB and etc. These cloud databases are designed for cloud applications and is highly service oriented to scale unprecedentedly in a highly available and secure manner.
Taking advantage to create low risk initiatives to migrate at least some applications to these cloud databases can result in elimination of years of technical debt inflicting your IT environment.
So, where to get started ?
Identify the open-source equivalent of your commercial database/s
Best method is to start from DBMS systems that contributes to a significant share of the licensing cost and prioritise those pending upgrades and require additional licensing. Identify how many applications are affected, documentations, customisions and integrations to external systems.
Research potential open-source databases and their fit to replace your current commercial databases. Upon a selection, start segregating apps that can and cannot be migrated to the new target database.
Identify cloud based open source database providers....
Next research and identify cloud vendors who provide DBpaas services for open source and cloud based databases. Most cloud vendors such as Aws, GCP, Ali, IBM, Azure provide services for MySQL, PostgreSQL, Maria DB, MongoDB, Firestore and other popular open-source databases. They manage bug fixes, patches, upgrades and scaling, along with day to day operations enabling a far less number of DBAs to manage a bigger number of database clusters.
Rate migration complexities for each app...
Once service providers of choice are identified, explore portfolio of tools provided and recommended by user communities (3rd party) to make an initial assessment on migration complexities of the selected applications. When choosing or building migration tools, think of repeatable usage for both data and refactoring requirements.
Once the potential tools are selected run some initial rest to rate apps, based on migration complexities (single step, multiple step, data size, refactoring levels) and other criterias such as critical app, number of users and etc. At the end of the phase select your pilot case or cases.
Contact 1 or 2 cloud providers to start experimenting...
Next contact your current or suitable cloud providers to compare services and pick one that best suit your business in the long run. You can decide this based on range of service offerings, supported open-source DBMS and cloud databases, price-service effictiveness, cloud eco system offered (other services, partners, user communities, availability zones and etc).
Upon selection of vendor, start experimenting your pilot cases ranging from low to high complexity. Document challenges faced and resolved with future migrations in mind, which means processes must be repeatable and automated as much as possible.
Create a migration schedule and milestone for large scale impact
Having assessed pros and cons of migrating to open-source databases operations to the cloud, build a schedule for migrating apps to the cloud and start executing them in line with business objectives. Leave room for changes in the event new priorities enters the business.
Start large scale migration of all target environment..
Upon completion of pilot migration case, refining and further automation of tools start to migrate applications with low complexities first to the new cloud based open-source database, one at a time.
Address any refactoring needs and test each service before moving to the next, till all low complexity migrations are completed. Repeat the process for complex migration projects. Keep updating schedules, findings and refine tools if neccesary.
Relieve resources for high impact projects
At the end of this process, your team would have not only realised licensing reduction and much stable performance of your databases powering critical applications but eliminated at least some technical debt around critical applications and relieved valuable IT resources for other high impact projects to build new business capabilities, improve access to business insight and performance of queries instead of maintaining 'lights on' projects.
Navigating Values - Cost, Technology Debt, Data ROI and IT Resources
Often a open-source database adoption is initiated due to lack of funds for commercial databases or to cut back on commercial licenses that results in millions of dollars of recurring cost.
Cost
But moving to a cloud provider and consuming DBpaas services results in cost reduction in all types of licensing including those used in ETL processes. In addition , users need not incur cost until a demand arises. This changed how tech organisations plan for future needs, while allocations are made, they don't have to be spent until need arise.
Technology debt that hinders availability, scalability and security design
Another key value is the migration process trigger application modernisation activities to refactor key business solutions on premise to scale and perform better in the cloud both public and private. Migrating to cloud based databases such as Aurora and Azure increases these values by leveraging services enabling high availability, concurrency, business continuity, security, and scallibility.
IT Resources
These values are best navigated with scale of adoption horizontally and vertically. The wider the adoption the higher the value accross the organisation, freeing resources time, money and people to do what matters most to your growth - improving experience for customers, creating business innovation, increasing efficiencies and speed to react to market opportunities.
Since then these RDBMS have evolved into a common IT staple for managing clusters of structured and unstructured data in business environment of any sector. In fact, they have a strong influence on how applications were designed and built in the past.
Most RDBMS vendors also built prepackaged applications that resided on their RDBMS systems further locking customers into their environment, though it must be noted that many of these applications were the foundation for business process automation and integrations that drove workforce productivity.
The complexities of running open-source databases in house..
Growing data and high cost
While many of these solution resulted in high performing systems of the time (pre cloud era) over the years businesses started to incur high cost to maintain the exponentially growing organisational data due to automation, mobility, web and sensors. These included DB licenses, ETL related tools and software licenses, storage, compute, and increasing number of human resources to administer performance of the data layer empowering various business processes.
Migration to open-source databases..
In much recent times, businesses have been experimenting with open-source databases for some applications where data growth is significant in order to cut database licensing cost. But this attempt resulted in various problems such as limited features (or features are not as robust as commercial systems), steep learning curve, expensive support and constant config, bug fixing, patching and performance tuning activities. While businesses were able to escape the licensing cost, maintaining a dedicated database team that keeps the open-source databases at an optimal level was a time consuming and arduous effort on the organisation's part.
Scaling based on forecast demand
To add salt to the pain, all of these cost are incurred based on forecasted demand as most businesses are scaling systems in a conventional environment (without cloud capabilities) which means cost is incurred way before the business hits the projected demand. Though this is a universal problem with most conventional IT architectures that lacks cloud capabilities to instantly provision, scale, update, patch and de-provision based on internal demand.
New cloud based applications and microservices...
As we enter the cloud era, application architectures started to take effect of the SOA capabilities of cloud, with high levels of abstraction in every layer (e.g infrastructure, data, intergration and application).
A polyglot architecture where developers can take advantage of the best DBMS, programming language and other ready cloud services including AI, IOT, and Bigdata that accelerates application delivery, begin to take center stage. Apart from SQL type of DBMS, no SQL requirements to support other data types such as value store, document, graph, time series and in-memory DBMS started to emerge as demand rises to 40%. All of a sudden, purpose built DBMS were starting to look much appealing to developer communities every where as opposed to multi models.
Choosing to build such an applications on commercial database can make projects less viable in terms of both cost and feature sets required for a cloud environment where service orientation and scaling instantaneously based on demand is of high importance.
Why cloud based open-source databases are a good option?
Thanks to increasing popularity of public clouds, open-source databases today are mature enough in terms of features and support for wider adoption in businesses including large enterprises.
Overcome management constraints posed by on premise deployments...
It's common to find MySQL, PosgreSQL, MariaDB, MongoDB and countless others in organisations' on premise environment, underpinning many critical business application both prepackaged and customised, but then those implementations are plagued with similar issues surrounding commercial databases such as scalability, availability, security and high operational cost to keep it updated and running.
Cloud providers' DBPaas services eliminates this issue by removing day to day operational complexities from businesses that just want to use the services to build various business solutions to increase quality of engagement with existing and new types of audiences.
Wider adoption and value extension is now possible....
With database administrative task out of the equation, tech teams can now focus on migrating more applications on open-source databases for better value and standardisations within the organisations.
High priority business requirements can be addressed much faster than before with available team and funds, curbing the need for any shadow IT by LOBs.
Refactor apps for the cloud..
Another indirect benefit of this exercise is to modernise legacy applications sitting on premise environments. The migration process is an excellent opportunity to learn more on what pure cloud based databases can do for some applications.
Many cloud databases such as Aurora, Dynamodb, Azure, Google Cloud Bigtable, Google Cloud Datastore, Aspara and DocumentDB are quickly maturing in feature sets and support for other open-source database engines especially MySQL, PostgreSQL, MariaDB and etc. These cloud databases are designed for cloud applications and is highly service oriented to scale unprecedentedly in a highly available and secure manner.
Taking advantage to create low risk initiatives to migrate at least some applications to these cloud databases can result in elimination of years of technical debt inflicting your IT environment.
So, where to get started ?
Identify the open-source equivalent of your commercial database/s
Best method is to start from DBMS systems that contributes to a significant share of the licensing cost and prioritise those pending upgrades and require additional licensing. Identify how many applications are affected, documentations, customisions and integrations to external systems.
Research potential open-source databases and their fit to replace your current commercial databases. Upon a selection, start segregating apps that can and cannot be migrated to the new target database.
Identify cloud based open source database providers....
Next research and identify cloud vendors who provide DBpaas services for open source and cloud based databases. Most cloud vendors such as Aws, GCP, Ali, IBM, Azure provide services for MySQL, PostgreSQL, Maria DB, MongoDB, Firestore and other popular open-source databases. They manage bug fixes, patches, upgrades and scaling, along with day to day operations enabling a far less number of DBAs to manage a bigger number of database clusters.
Rate migration complexities for each app...
Once service providers of choice are identified, explore portfolio of tools provided and recommended by user communities (3rd party) to make an initial assessment on migration complexities of the selected applications. When choosing or building migration tools, think of repeatable usage for both data and refactoring requirements.
Once the potential tools are selected run some initial rest to rate apps, based on migration complexities (single step, multiple step, data size, refactoring levels) and other criterias such as critical app, number of users and etc. At the end of the phase select your pilot case or cases.
Contact 1 or 2 cloud providers to start experimenting...
Next contact your current or suitable cloud providers to compare services and pick one that best suit your business in the long run. You can decide this based on range of service offerings, supported open-source DBMS and cloud databases, price-service effictiveness, cloud eco system offered (other services, partners, user communities, availability zones and etc).
Upon selection of vendor, start experimenting your pilot cases ranging from low to high complexity. Document challenges faced and resolved with future migrations in mind, which means processes must be repeatable and automated as much as possible.
Create a migration schedule and milestone for large scale impact
Having assessed pros and cons of migrating to open-source databases operations to the cloud, build a schedule for migrating apps to the cloud and start executing them in line with business objectives. Leave room for changes in the event new priorities enters the business.
Start large scale migration of all target environment..
Upon completion of pilot migration case, refining and further automation of tools start to migrate applications with low complexities first to the new cloud based open-source database, one at a time.
Address any refactoring needs and test each service before moving to the next, till all low complexity migrations are completed. Repeat the process for complex migration projects. Keep updating schedules, findings and refine tools if neccesary.
Relieve resources for high impact projects
At the end of this process, your team would have not only realised licensing reduction and much stable performance of your databases powering critical applications but eliminated at least some technical debt around critical applications and relieved valuable IT resources for other high impact projects to build new business capabilities, improve access to business insight and performance of queries instead of maintaining 'lights on' projects.
Navigating Values - Cost, Technology Debt, Data ROI and IT Resources
Often a open-source database adoption is initiated due to lack of funds for commercial databases or to cut back on commercial licenses that results in millions of dollars of recurring cost.
Cost
But moving to a cloud provider and consuming DBpaas services results in cost reduction in all types of licensing including those used in ETL processes. In addition , users need not incur cost until a demand arises. This changed how tech organisations plan for future needs, while allocations are made, they don't have to be spent until need arise.
Technology debt that hinders availability, scalability and security design
Another key value is the migration process trigger application modernisation activities to refactor key business solutions on premise to scale and perform better in the cloud both public and private. Migrating to cloud based databases such as Aurora and Azure increases these values by leveraging services enabling high availability, concurrency, business continuity, security, and scallibility.
IT Resources
These values are best navigated with scale of adoption horizontally and vertically. The wider the adoption the higher the value accross the organisation, freeing resources time, money and people to do what matters most to your growth - improving experience for customers, creating business innovation, increasing efficiencies and speed to react to market opportunities.
No comments:
Post a Comment