Re-engineering services

Kloudone can help your application evolve into a fully containerized cloud native application with our cloud migration services.

What is Re-engineering?


Re-engineering to a SAAS application that is fully containerized, elastic and is completely cloud native can be daunting and complex. With a proven cloud practice, usage of industry standard tools, approaches - Kloudone can help deliver to your migration needs.

Re-engineering resources

We've curated best resources from the internet on re-engineering for your reference.

Re-engineering - what does it mean?



Reengineering often involves rewriting the application architecture to become cloud native. Typically this is called Software as a Service (SAAS) migration, as it enables the software to be delivered as a service.

The migration complexity during re-engineering can be very high compared to all other methods.

Reverse engineering, redesign structure, forward engineering might need to be done in order to move the application to the cloud.

Cloud computing involves metered access to resources. To that effect, it is important to build software with resource economy as a priority, If done otherwise, operating costs can become prohibitive.

Our approach: We start re-engineering by executing the following tasks

  • Runtime profiling of application and data storage systems
  • Use of performance and resource monitoring tools
  • Review of application and system logs
  • Workload statistics – number of users, response times, transaction volumes, data volumes


Automated service discovery

We will perform an automated service, applications discovery using a tool like iQuate so that an asset list can be made and fed into a CMDB.

What is required
  • All services running, versions, installed configuration. Including all installed software and running processes.
  • Services Running
  • Deployed applications & components
  • All network ports open
  • All containers running and their dependencies
  • Discovery of high value infrastructure software assets including database and middleware products.
  • DB usage - version, option pack and current usage.
  • Installed Software
  • Ports in use by each process
  • the remote IP Address
  • User Configuration
  • Automated Oracle discovery - versions, service packs, edition, configuration information, clustering information.
  • Clustering information specific to Oracle
  • Application and network topology and interdependencies, including reverse proxy load balancers

Application performance snapshot

An automated application performance snapshot taken by a tool like AppDynamics. Why is this useful?
  • A baseline of performance measured pre-migration, against individual assets helps us measure the performance of the application AFTER migration.
  • It is very important to do an automated measurement (saves time, effort) during the migration process.
  • Performance to be measured at each individual asset level, or as a logical group (example database cluster).

    How do these metrics need to be measured?
  • Either in a staging environment, or in production with full load simulated.
What metrics:
  • CPU
  • Memory usage
  • Disk usage at DB layer (Throughput - MBPS, IOPS, disk)
  • Network usage (IOPS, throughput in MBPS, latency for writes)
  • JVM or container heap allocation vs utilization
  • Top processes consuming CPU
  • Network ports and traffic statistics on each
  • Baseline performance (all metrics), across all apps as recorded by AppDynamics: https://www.appdynamics.com/how-it-works/application-performance-baseline/
  • Snapshot of Oracle using ADDM during peak and normal workload
  • Snapshot of MySQL using status variables during peak and normal workload
  • Snapshot of Database performance
  • Read throughput and performance (IOPS or KBPS) of database in use.
  • Write throughput and performance (IOPS or KBPS) of database in use.
Based on the outcome of the previous steps, we would decide the following
  • Deployment and infrastructure
  • Host configuration
  • Database design
  • Format and structure of data
  • Application security
  • Communication interface design
  • Static code analysis
  • Application data caching
  • Application state management
  • The user interface

Migrating to microservices architecture

There are key advantages that we want to derive by implementing solutions as microservices. We can study that by understanding the characteristics of typical Microservices architecture.

Characteristics of Microservices architecture.
Microservices are built to be independent Microservices are built to be independent as a component, and can be independently built and independently deployed.
Microservices are grouped or organized around specific business requirements.
A microservice is typically built around a common business function, or specific requirements. This is the only logical boundaries for microservices as there are no other hard rules to define the same. By organizing as a business function, teams building a specific microservices can focus on solving all facets of the problem relating to a business function as opposed to a horizontally organized organization where each change impacts every team.

Microservices can be independently deployed
The fact that it can be independently deployed means small pieces of our application can now be deployed in a silo without impacting the other pieces. And as long as there are blue/green deployments - customers won't even notice changes to the platform architecture as it is getting updated.

De-coupled
The other advantage of using microservices over a monolith is the fact that the components are typically de-coupled from each other and as opposed to talking to each other using proprietary, binary protocols - lightweight, non binary protocols are used to facilitate cross component communication.

Decentralized data
Microservices are typically decentralized with their own logical data in isolation from other parts of the application. This again allows for changes to be done effectively (without breaking other dependencies).

Microservices can be polygot; and blackboxes
Distinct microservices can be built on different stacks and built as black boxes hiding the complexity of the same from other consumers of each microservice.
Read more at our blog

Kubernetes

Kubernetes is experiencing phenomenal growth since it solves specific pain points with respect to application portability and deployment.
Kubernetes is already a reality in eliminating vendor lock-in and enabling cloud portability with the choice of offerings on the different clouds.
Kloudone has an exhaustive kubernetes practice in place to help re-engineer services to the cloud.
For more information, Get in touch with us.


Who do we do it for?

$200 Billion US Public Hardware and Software Company

KloudOne's team led re-engineering for a multi-billion dollar enterprise in the bay area for Lift and Shift to GCP Legacy Product Modernization

$10M CyberSecurity Software Company

KloudOne led legacy product re-development including Re-engineering complex pieces for simplicity Introducing large scale data processing pipeline Lifting / Shifting applications to make it cross cloud compatible

Telecom grade mobile advertising engine

KloudOne led product development including Introducing large scale data processing pipeline Lift and shift of existing components form AWS to GCP Build a DMP at scale(100k QPS) CI/CD pipeline with Docker/Kubernetes