Cloud-Native Development

Cloud-native development is designing and building software to run on managed cloud services, using containers and service boundaries where the design needs them. SEYA Group builds new products this way and refactors existing applications onto it, for teams whose software works but has become too slow or too risky to change.

Who this is for

CTOs and VPs of engineering who own an application that generates revenue and treat every release as a risk. Solution architects who have been asked to split a monolith and want a second opinion on where the seams are. IT managers whose application was lifted into the cloud as-is and still carries its data-centre assumptions, so the cloud bill went up and the release cadence did not change.

If you need many workloads moved with minimal change, that is cloud platform and migration. This page is for the application that needs its design changed.

Problems we solve

• A product that cannot be changed safely because every part depends on every other part.
• A codebase shaped around fixed servers, shared disks, or a single database that cannot scale.
• A release path that assumes one deployable, one environment, and a maintenance window.
• A new service that has to be built and there is no agreed pattern for how services are built here.
• Integrations that are hand-wired and break when either side changes.

What you get

• Target design. How the application splits into services, where containers, Kubernetes, serverless functions, or a simpler runtime fit, and which managed services replace what you run yourself.
• Working software. The new product or the refactored application, built with your engineers, in your repositories, on your cloud accounts.
• Delivery path. The build, test, and release pipeline for those services, so each one ships on its own.
• Interfaces. API and integration boundaries that other systems can call in a consistent way, documented for the teams that consume them.
• Cutover plan. For a refactor, a written statement of which behaviour must keep working and how traffic moves from old to new.

How an engagement runs

• Architecture call. You walk us through the application, the constraint it creates, and the behaviour that cannot break.
• Design. We read the code and the operational history with your team, propose service boundaries and a runtime, and agree the first increment.
• Build in increments. Services are built, tested, and released one at a time, with your engineers pairing on the work so the patterns stick.
• Cutover and handover. Traffic moves according to the plan, the old path is retired when you say so, and your team owns what runs.

Technical scope

SEYA has built and refactored applications on AWS, Microsoft Azure, and Google Cloud. Container work has used Docker, Kubernetes (including Amazon EKS and Google Kubernetes Engine), Istio, and OpenShift; serverless work has used AWS Lambda. Application code has included Java with Spring Boot and Spring Cloud, Node.js, and Python. Delivery pipelines have used Jenkins and GitHub Actions, with Terraform for the infrastructure the services run on. Kubernetes is recommended when the architecture calls for it, and a simpler runtime when it does not.

What you need in place

A product owner who can rank which behaviours matter most, engineers who will work with us and take over the result, and a cloud account the services can run in. If no foundation exists yet, the landing-zone part of cloud platform and migration comes first. Security checks in the pipeline are designed under security and DevSecOps, and changes to how your teams are organised are enterprise transformation.

Out of scope here: a whole-portfolio modernization program in one brief (the engagement covers the application named in it), brand or marketing work, and running your Kubernetes clusters for you after handover.

Security

Pipeline checks, secrets handling, and admission rules for the application are designed under DevSecOps. This page covers the application build. It does not replace that review, and it does not certify the result.

Related work

• Clearly: refactoring an e-commerce platform onto AWS with autoscaling, service discovery, and a pipeline as code
• LiveRamp: GKE and shared-VPC design for a first Google Cloud environment

Questions buyers ask

Do we have to use Kubernetes?

No. Kubernetes is one option, and it carries operating cost. The design phase recommends the runtime that fits the application and the team that will run it, which is sometimes a managed container service or serverless functions.

Who owns the code?

You do. Work happens in your repositories, under your licences, from the first commit. There is no SEYA framework you become dependent on.

How do you work with our engineers?

As one team. SEYA engineers pair with yours on design and implementation, and reviews run through your normal process. The intent is that your team can carry on without us.

Can the old application keep running during the refactor?

That is the normal approach. The cutover plan states which behaviour must keep working and moves traffic in stages, so the business keeps operating while the new services take over.

How long does the design phase take?

It depends on the size of the application and how much of its behaviour is documented or covered by tests. We agree the scope of the design phase in the architecture call and tell you if it needs to grow.

If one application is slowing your whole product roadmap, book an application architecture call and we will tell you where we would start.