Why is your GIS software architecture not cloud-native? You moved your GIS server to the cloud, so is your GIS architecture cloud-native?
Answer: If you just move your GIS server to AWS or Azure, then your SDI is not cloud native. This is called re-hosting or Infrastructure as a Service (IaaS). You might get some benefits from a cloud-managed database like AWS RDS, and your single GIS server instance can be scaled as needed. However, you don't have a truly elastic and scalable infrastructure that a cloud-native architecture can provide.
And what does this mean?
- Scale Out expansion
To achieve true scalability, you need to scale multiple servers behind the load balancer. See the Esri solution below.
Multi-machine deployment of GIS server cluster
Unfortunately, this solution is static (not just because you need to purchase a core license from Esri in advance). There is no automatic mechanism for adding instances to the cluster. Enter the AWS auto-scaling group. AWS provides dynamic load balancing, and the autoscaling group automatically adds and deletes EC2 instances to the cluster as needed.
In order for all of this to work, the server must be stateless. In the Esri example, you may have noticed that the "server directory and configuration store" are located in a shared network directory. This serves two purposes. You need to store cached tiles and configuration metadata about services and layers. Let's see how to improve this.
- Service Metadata and Tile Caches
First let's store the metadata of services and layers in the database. One advantage of this method is that we don't need to make a separate backup plan for the server configuration and database, and we can easily query the configuration if necessary. Don't worry, we can store multiple connections in the metadata so that our operational database can be selectively separated from the metadata database.
Then let's cache all metadata in Elasticache Redis for super fast memory access. Now, we have done our best in both service and layer metadata: speed and durability.
Next let's check our tile cache. It can be a raster slice or MVT. Let's put all the slices in an S3 bucket, and then put Cloudfront CDN on it. Don't forget to delete all these blank raster tiles to optimize storage. Can you feel that your map has become smoother and more sensitive?
- Big Data
If your database cannot scale with you during the inevitable IoT/drone/computer vision geographic data analysis, what good is it to be able to serve millions of web requests per second? The same horizontal scaling concept also applies, so that you can perform large-scale parallel query processing. You can use Hadoop, but those who know how to write map reduce functions in geospatial are very expensive and even a bit snobbery. JK Corporation.
If there is a big data repository with spatial query capabilities, it has a traditional query interface so you can connect it to your analysis and reporting tools (such as Tableau), that would be great. good news! There are two types of big data databases: MemSQL with MySQL interface and Citus data with PostGIS interface.
- GeoEvents (geographical affairs)
Let us introduce the processing capabilities of geoevent. Real-time mapping can be achieved through websockets, webhooks and/or Pubnub. For geofencing, you should consider Azure Stream Analytics that includes key geospatial features.
- Composable (composable)
AWS CloudFormation templates allow you to combine and adjust the infrastructure stack as needed through a declarative model. Think of it as a flexible cloud installer that can automate your devops and infrastructure processes. If you are not familiar with this concept, please read the infrastructure code.
- Accessible (available)
The cloud application store is open! It is called the AWS market. As an enterprise application buyer, if you only deal with the AWS market, won't it simplify your trial, environmental supply and procurement? If you can build a complex spatial data infrastructure stack from the market in less than an hour with just a few clicks, will it be easier for you? I am not saying that there is only one AMI instance available.
- Azure / Docker / Kubernetes
All these cloud-native things can be done in Azure and various Docker orchestration platforms (which can be in Azure, AWS or on-premises). For the sake of simplicity, I chose to use some AWS and auto-scaling group examples to illustrate a popular form of cloud-native infrastructure. Use the following examples of similar techniques to compare the options with awsazure and Docker. (Excluding Google Cloud Platform)
- Compatibility
- Shameless Plug advertise
If you want to see how all this works in real life for one of the top brands in the world get in touch - [email protected]. Also check out some product videos to see how we make publishing Esri and OGC compatible location data services super simple. We are currently accepting a limited number of pilot customers where we leverage automation to migrate your data and services / layer configuration from ArcGIS Server to the cloud for free while maintaining compatibility with your existing Esri applications and tools.
https://www.linkedin.com/pulse/cloud-native-gis-architecture-mike-mcdougall/
The above is an article on LinkedIn about cloud-native GIS. In fact, I think the following article is better
https://blog.csdn.net/supermapsupport/article/details/85988021