I'm working on a cloud based solution architecture at the moment and want to take the approach of using an immutable server infrastructure (creating and then deploying new AMIs when updating software, OS, etc). There's plenty of good reading and presentations out there in terms of the approach and the various tooling to use, and I'm aware of the virtues of stateless web/application servers and using the likes of AWS RDS to take away some of the headaches in managing the data tier.
However, I was wondering how to approach some of the management services/servers that sit around the application server estate from an immutable perspective. I can appreciate how the likes of AWS RDS take away some of the complications of maintaining the data tier from an immutable perspective, but how you would approach some of the other 'less stateless' servers/services that typically make up a solution? I'm thinking of things like the CI server e.g. Jenkins, Directory Services, Monitoring/Logging Services, etc. I suppose I could look to engage 3rd party services for some of these things, like the approach with AWS RDS, but what other approaches exit? What alternative approaches are there to maintain these servers and services without deviating widely from the immutable server deployment approach?
Thank you.
Related
I'm working on a SaaS application which at the moment is cloud only. It's a traditional Java web application which we deploy to AWS. We rely on AWS concepts like RDS, S3, ELB, Autoscaling and for infrastructure provisioning AMIs, Cloudformation, Ansible and CodeDeploy.
There is now more and more demand for on-premise deployments by potential clients.
Are there any common approaches to package b2b applications for on-premise deployments?
My first thought would be to containerize the app infrastructure (web server, database, etc) and assume a client would be able run images. What are you guys doing and how do you tackle HA and DR aspects which come with cloud infrastructure like AWS?
I'm tackling a similar problem at the moment and there really is no one-fits all answer. Designing software for cloud-nativity comes with a lot of architectural design decisions to use technologies on offer by the platform (as you have with S3, RDS, etc) which ultimately do not cross-over to majority of on-premise deployments.
Containerising your application estate is great for cross-cloud and some hybrid cloud portability but there is no guarantee that a client is using containerised work-loads on their on-premise data centre which makes the paradigm still a way off the target of supporting both seamlessly.
I find another issue is that the design principles behind cloud-hosted software are vastly different to those on-premise, with static resource requirements, often a lack of ability to scale etcetera (ironically some of the main reasons you would move a software solution to a cloud environment) so trying to design for both is a struggle and I'm guessing we will end up with a sub-optimal solution unless we decide to favour one and treat the other as a secondary concern.
I'm thinking maybe the best cross-breed solution is to concentrate on containerisation for cloud hosts taking into account the products and services on offer (and in the roadmap) - and then for making the same software available to clients who wish to use on-premise datacenters still.... perhaps they could be offered VM Images with the software solution packaged in... then make this available on a client portal for them with instructions on installation/configuration.
... I wish everyone would just use Kubernetes already! :)
I am designing a software architecture for our client, i am aware of cloud-enabled and cloud-native architecture terminology. I have read lots of articles on cloud-native, though when i talk to other tech people about cloud-native architecture i got confused. cause most of people have impression that cloud-native architecture is a one which runs in containers on Kubernetes.
My question is if i am designing cloud-native architecture and deploy it in AWS cloud, can i use AWS managed services apart from docker containers in my architecture or cloud-native architecture is completely independent of cloud services ?
It's tricky to find consensus on definitions here, but in my own experience the term 'cloud-native' is definitely increasingly container- and microservice-specific, with Kubernetes as the de-facto poster boy. A definition from the CNCF is available here.
The baseline appears to be an abstraction above infrastructure, with a focus on portability and reproducibility, avoiding lock-in where possible. That said, managed services from particular providers do abstract responsibility for infrastructure quite successfully, so may be desired.
In this scenario, you may wish to declare your infrastructure configuration using a neutral method, like Terraform, and therefore reduce some inherent friction around portability, while still being able to make use of managed services.
The general term cloud-native refers to an application which is entirely deployed in public cloud, and uses the services provided by a particular cloud provider (infrastructure management, message passing, etc.)
This is, of course, opposed to the classical model where you had to manage the infrastructure and take care of provisioning, availability and so many other things.
The confusion might arise from the fact that there is Cloud Native Computing Foundation, which is an open source organisation that promotes cloud adoption and manages the development of Kubernetes, Prometheus and other very successful open-source projects.
So people may refer to cloud-native apps as being apps which use all (or many) projects maintained by CNCF, including Kubernetes.
To avoid the confusion, you can use the term cloud-based to refer to an app that is entirely deployed in cloud and it's not necessarily linked to CNCF projects.
We are deploying a data consortium between more than 10 companies. Wi will deploy several machine learning models (in general advanced analytics models) for all the companies and we will administrate all the models. We are looking for a solution that administrates several servers, clusters and data science pipelines. I love kedro, but not sure what is the best option to administrate all while using kedro.
In summary, we are looking for the best solution to administrate several models, tasks and pipelines in different servers and possibly Spark clusters. Our current options are:
AWS as our data warehouse and Databricks for administrating servers, clusters and tasks. I don't feel that the notebooks of databricks are a good solution for building pipelines and to work collaboratively, so I would like to connect kedro to databricks (is it good? is it easy to schedule the run of the kedro pipelines using databricks?)
Using GCP for data warehouse and use kubeflow (iin GCP) for deploying models and the administration and the schedule of the pipelines and the needed resources
Setting up servers from ASW or GCP, install kedro and schedule the pipelines with airflow (I see a big problem administrating 20 servers and 40 pipelines)
I would like to know if someone knows what is the best option between these alternatives, their downsides and advantages, or if there are more possibilities.
I'll try and summarise what I know, but be aware that I've not been part of a KubeFlow project.
Kedro on Databricks
Our approach was to build our project with CI and then execute the pipeline from a notebook. We did not use the kedro recommended approach of using databricks-connect due to the large price difference between Jobs and Interactive Clusters (which are needed for DB-connect). If you're working on several TB's of data, this quickly becomes relevant.
As a DS, this approach may feel natural, as a SWE though it does not. Running pipelines in notebooks feels hacky. It works but it feels non-industrialised. Databricks performs well in automatically spinning up and down clusters & taking care of the runtime for you. So their value add is abstracting IaaS away from you (more on that later).
GCP & "Cloud Native"
Pro: GCP's main selling point is BigQuery. It is an incredibly powerful platform, simply because you can be productive from day 0. I've seen people build entire web API's on top of it. KubeFlow isn't tied to GCP so you could port this somewhere else later on. Kubernetes will also allow you to run anything else you wish on the cluster, API's, streaming, web services, websites, you name it.
Con: Kubernetes is complex. If you have 10+ engineers to run this project long-term, you should be OK. But don't underestimate the complexity of Kubernetes. It is to the cloud what Linux is to the OS world. Think log management, noisy neighbours (one cluster for web APIs + batch spark jobs), multi-cluster management (one cluster per department/project), security, resource access etc.
IaaS server approach
Your last alternative, the manual installation of servers is one I would recommend only if you have a large team, extremely large data and are building a long-term product who's revenue can sustain the large maintenance costs.
The people behind it
How does the talent market look like in your region? If you can hire experienced engineers with GCP knowledge, I'd go for the 2nd solution. GCP is a mature, "native" platform in the sense that it abstracts a lot away for customers. If your market has mainly AWS engineers, that may be a better road to take. If you have a number of kedro engineers, that also has relevance. Note that kedro is agnostic enough to run anywhere. It's really just python code.
Subjective advise:
Having worked mostly on AWS projects and a few GCP projects, I'd go for GCP. I'd use the platform's components (BigQuery, Cloud Run, PubSub, Functions, K8S) as a toolbox to choose from and build an organisation around that. Kedro can run in any of these contexts, as a triggered job by the Scheduler, as a container on Kubernetes or as a ETL pipeline bringing data into (or out of) BigQuery.
While Databricks is "less management" than raw AWS, it's still servers to think about and VPC networking charges to worry over. BigQuery is simply GB queried. Functions are simply invocation count. These high level components will allow you to quickly show value to customers and you only need to go deeper (RaaS -> PaaS -> IaaS) as you scale.
AWS also has these higher level abstractions over IaaS but in general, it appears (to me) that Google's offering is the most mature. Mainly because they have published tools they've been using internally for almost a decade whereas AWS has built new tools for the market. AWS is the king of IaaS though.
Finally, a bit of content, two former colleagues have discussed ML industrialisation frameworks earlier this fall
Last month there was an outage in AWS and some sites had to be taken down because of that. I was wondering if a company is availing both AWS and Google Cloud Platform for hosting, how easy would it be for them to easily transfer their services from the Amazon platform to the Google platform or vice versa ( In case Google Cloud has some outage) . First of all is it possible or not? And also if it's what would be the cost for performing such an activity and how much time will it take to get the services running back again.
In this I also did some digging up and what I came across was each of the providers (Google and Amazon) have tools of their own to do so i.e. for transferring the stored data from other platforms to their platform -
https://cloud.google.com/storage/docs/migrating?hl=en
https://aws.amazon.com/importexport/
Are these the only options available or there is anything else as well. Hope some AWS/Google cloud expert would be able to answer my question.
You would need to run your application in both environments, keep the deployments in sync, keep the databases in sync, etc. That can get complicated and expensive...
Then to automatically fail over from one environment to another you could use a DNS service such as DynDNS Active Failover that monitors the health of your application and starts sending traffic to the other environment if your primary environment becomes unhealthy.
How you manage deployments, how you continually ship data across environments, how much all that will cost, all those questions are extremely specific to the technologies (programming languages, operating systems, database servers) you are currently using. There's no way to give details on how you would accomplish those tasks without having all the details of your system.
Further, if you are using proprietary technologies on a specific platform, such as Amazon Redshift or DynamoDB, you might not find a service on the other platform that provides the same functionality.
I've seen this subject come up a lot since the last AWS outage, but I think maintaining two environments on two different platforms is overkill for all but the most extremely critical applications. Instead, I would look into maintaining a copy of your application in a different AWS region, and use Route53 health checks to fail-over.
We use AWS as a sort of developer playground --- turning on a server to test app deployment, and execution with a variety of non production data, and then turning it off again.
We also use AWS as a host for our TFS. (because somehow our source code "isn't production data" All in all it's been great, and I would recommend it for corporate work, but that idea doesn't seem to get any traction here. The business is very reluctant to put their data "outside the wire"
What's missing from AWS, and its competitors, to make it a suitable enviornment for private coprorate use.
IMO EC2 is well suited for corporate use - as long as you back up all your critical data off site in case of an outage, which you'd want to do for internal systems anyway. The minimum level of security that Amazon enforces is well above what a lot of traditional hosting providers give you, and also above a lot of internal shops I've worked with. Since you have full access to the operating system, you can add in as many extra levels of security as you like.
Ubuntu offer a cloud solution that you can run within your network if management is worried about information going outside of the corporate firewall.
Details can be found at: http://www.ubuntu.com/products/whatisubuntu/serveredition/cloud
From thier website:
Ubuntu Enterprise Cloud brings Amazon
EC2-like infrastructure capabilities
inside the firewall. The Ubuntu
Enterprise Cloud is powered by
Eucalyptus, an open source
implementation for the emerging
standard of EC2. This solution is
designed to simplify the process of
building and managing an internal
cloud for businesses of any size,
thereby enabling companies to create
their own self-service infrastructure.