Your Cart is Empty
Serverless Geospatial - Serverless architectures provide an instantly scaleable application environment so that IT infrastructure may dynamically scale up and down to meet the demand of both machine and human users. In this interview with Tomas Holderness walks us through the pro's and con's of serverless architecture with regard to geospatial use cases
Serverless computing or serverless architectures are managed services by a cloud provider, such as Amazon, Google, or Microsoft. Serverless computing goes one step beyond cloud computing where virtual machines are rented from a cloud vendor, as it enables cloud-based applications that can scale up and down automatically without having to manage these yourself. With regards to geospatial, serverless geospatial means harnessing this new technology to build geospatial applications with big data requirements for many different users.
Rather than paying for a server in the cloud that runs all the time, users of serverless architecture pay for per execution. The term execution can mean multiple things, from executing a function each time a user request comes in, or when retrieving data from a database. Without having to worry about managing physical infrastructure, serverless architectures enable geospatial organizations to focus on the thing that gives them a competitive edge, which is providing high-quality spatial data and location services to their users.
Although European organizations are generally not allowed to host their data outside of the European Union and therefore cannot host their data in the cloud, cloud providers have solved this problem using regions. This means that organizations can specify which region and set of data their serverless data resides within.
When it comes to billing for serverless architecture, a different mindset is required than for traditional software architecture where billing is based on provisioning for peak capacity. Because serverless architecture can scale almost infinitely, all that is required is an expectation of the top number of simultaneous users that will access the service. Although dependent on the application architecture and what an application is trying to achieve, a serverless model most often works out cheaper than other models, especially when organizations must deal with the demands of scaling up or down.
However, serverless architecture is not a one size fitsall solution. There are three main use cases where serverless architecture is a good fit and will offer the most benefits in terms of cost savings and flexibility. First, when there are large datasets coming into an organization from different sensors, be it from humans or machines. Second, when there’s a lot of different users who are submitting queries simultaneously or looking at hosted maps in real-time. Third, when organizations are running a short lift task that’s highly parallelizable, so that they only pay for what they use.
In the current marketspace, there are multiple cloud providers offering different serverless services which makes it hard to generalize for best practices when moving parts of a geospatial stack into a serverless environment. However, all of them are making it as easy as possible to consume serverless services. When looking at a simple geospatial stack that consists of a database, a server-side and a frontend mapping application, there are different options for converting one or more pieces into a serverless architecture.
Amazon forged ahead with the concept of a serverless database and now offers Amazon Aurora, which is a PostgreSQL-compatible database. This means that Amazon now offers PostGIS effectively as a serverless database. Additionally, Amazon will automatically take care of scaling that database when user demand goes up or scale down when no one’s using the service.
A traditional server-application would require running on a physical server, such as GeoServer or GeoDjango. With serverless architectures, the only thing that is required is a one-off function written in a text editor or using a programming language that is then upload as a ZIP file into the cloud, where it is run when an API request is received.
Instead of serving a web page by a web server, serverless enables running single page applications in a serverless hosted environment that functions as the frontend application. Instead of scaling up or down, you are paying for the number of people that make requests to that website.
However, it is not necessary to move all different parts of the stack into a serverless environment: what serverless allows organizations to do is to start to chip away from a big application stack and for example put their PostGIS database in a serverless data store to deal with high capacity without having to pay for the compute when no one’s using it.
When moving parts of a geospatial stack into a serverless environment, it is important to start identifying which bits can be moved without too much disruption. For geospatial organizations, a serverless PostgreSQL offers many opportunities. Next, it is recommended to upload a website into the cloud, whereas the middleware is more challenging. Again, it might be possible to break up the application into many smaller functions.
Currently, organizations are excited about the possibilities of using Docker and containers, which are a halfway house between physical compute and serverless. These are not reallyl serverless, as users are still managing the underlying hardware. However, over time this interest will wane as cloud providers will get better at offering serverless infrastructure that allows for serverless versions of GeoServer, instead of running GeoServer in a constrained containerized environment. Advanced tooling will create new opportunities for developing geospatial applications with serverless architectures. This will also create opportunities for running existing off-the-shelf applications in the cloud in a scalable way, such as QGIS.
To put it simply, point clouds are a collection of XYZ points that represent some real world object of nearly any scale.They can be generated in a few ways. As geospatial scientists, we mostly work with LAS/LAZ data collected by aerial LiDAR (light detection and ranging) scanners at varying scales, from landscapes, down to project sites. We may also derive point clouds from highly detailed orthoimagery of an area, such as from the products of a drone flight.
As a data scientist, you don’t just go in and solve problems. You make recommendations to multi-faceted issues so that you get a fantastic model in the end. You’ll also be advocating a better use and understanding of the data while you do that.
