There's documentation on Vertex AI online serving, but no mention of the underlying system being used other than "online serving nodes". Is it Datastore? Something else?
Related
The reason I write this post is I would like to avoid re-inventing the wheel if possible, as I think this is definitely a solved problem, but I am struggling to find a SaaS provider which offers an existing solution that fits my use-case.
The problem goes as follows:
I am running a fleet of data hungry IoT devices.
These devices need to send data to multiple 3rd party endpoints (all HTTPS).
Currently as each new endpoint is added, the mobile data usage (3G/4G/5G) scales in a linear manner, as it is sending to each 3rd-party from the IoT device itself.
Proposed solution:
The IoT devices transmit their data to a HTTPS "hub", this then forwards the data to a list of specified endpoints. Like how a HTTPS load-balancer would work, but operating in a send-to-all mode.
This would keep the IoT device data usage constant, while increasing the cloud data usage (which is orders of magnitude cheaper). Resulting in a cost saving.
Now I had imagined that this is a fairly common problem with IoT devices, but am struggling to find any provider offering this type of service already. I may be lacking knowledge of what terminology to search for if this already exists. If anybody knows the name of a service which offers something like this then this is the type of answer I am looking for.
Ideal features:
HTTPS retry. The service should cache a request if it fails to forward to one or more of the destinations, it should then attempt to re-transmit to the failed destinations after some amount of time.
A SLA regarding uptime, as downtime of this service would expectedly cause a larger outage than duplicating the requests in the original method.
Reverse proxy to preserve the original IP address if possible.
A web GUI (a nice-to-have but not essential).
If this doesn't exist I will likely write my own solution. Thanks in advance.
I know this question was already asked but I could not find a satisfying answer.
I started to dive deeper in building a real restful api and I like it's contraint of using links for decoupling. So I built my first service ( with java / spring ) and it works well ( although I struggled a bit with finding the right format but that's another question ). After this first step I thought about my real world use case. Micorservices. Highly decoupled individual services. So I made a my previous scenario and I came to some problems or doubts.
SCENARIO:
My setup consists of a reverse proxy ( Traefik which works as service discovery and api gateway) and 2 Microservices. In addition, there is an openid connect security layer. My services are a Player service and a Team service.
So after auth I have an access token with the userId and I am able to call player/userId to get the player information and teams?playerId=userId to get all the teams of the player.
In my opinion, I would in both responses link the opposite service. The player/userId would link to the teams?playerId=userId and vice versa.
QUESTION:
I haven't found a solution besides linking via a hardcoded url. But this comes with so many downfalls as I can't imagine that this a solution used in real world applications. I mean just imagine your api is a bit more advanced and you have to link to 10 resources. If something changes, you have refactor and redeploy them all.
Besides the synchonization problem, how do you handle state in such a case. I mean, REST is all about state transfer. So I won't offer the link of the player to teams service if the player is in no team. Of course I can add the team ids as attribute to the player to decide whether to include the link or not. But this again increases coupling between the services.
The more I dive in the more obstacles I find and I'm about to just stay with my spring rest docs and neglect the core of Rest which I is a pity to me.
Practicable for a microservice architecture?
Fielding, 2000
The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
Fielding 2008
REST is intended for long-lived network-based applications that span multiple organizations.
It is not immediately clear to me that "microservices" are going to fall into the sweet spot of "the web". We're not, as a rule, tring to communicate with a microservice that is controlled by another company, we often don't get a lot of benefit out of caching, or code on demand, or the other rest architectural constraints. How important is it to us that we can use general purpose components to exchange information between different microservices within our solution? and so on.
If something changes, you have refactor and redeploy them all.
Yes; and if that's going to be a problem for us, then we need to invest more work up front to define a stable interface between the two. (The fact that we are using "links" isn't special in that regard - if these two things are going to talk to each other, then they are going to need to speak a common language; if that common language needs to evolve over time (likely) then you need to build those capabilities into it).
If you want change over time, then you have to plan for it.
If you want backwards/forwards compatibility, then you have to plan for it.
Your identifiers don't need to be static - there are lots of possible ways of deferring the definition of an identifier; the most obvious being that you can use another identifier to look up the identifier you want, or the formula for calculating it, or whetever.
Think about how Google works - the links they use change all the time, but it doesn't matter because the protocol (refresh your bookmarked search form, enter your text in "the" one field, click the button) hasn't changed in 20 years. The interface is stable (even though the underlying spellings of the identifiers is not) and that's enough.
I have a website that could be visited by countries in different continentals. I noticed that most hosting companies have data centers in the US only, which might affect the performance when people from India, for example, are visiting the site. AWS and google own data centers all around the world, so would this be a better choice to solve the above-mentioned doubt? Are they using some technology that makes the website located in all datacenters ?
More about the website :
It is a dynamic website which depends heavily on the database. It mostly involves text. Few ajax code is there.
It is a Q & A website.
You would use some sort of load balancer.
Such as
AWS Elastic Load Balancing
Cloud Load Balancing
Cloud providers such as AWS has something called edge locations. When you deploy a website code, AWS will deploy the same code to edge locations around the world. When a user visits your website and the request reaches to AWS, AWS will redirect the requests to the edge location that is geographically closer to the user. So that the request will be served to the user faster.
I noticed that most hosting companies have data centers in the US only, which might affect the performance when people from India, for example, are visiting the site.
If your web site has purely or mostly static content, it usually won't matter (read about web caching), unless its traffic is large. As a typical example, I manage http://refpersys.org/ (physically hosted by OVH in France) and it is well visible from India: the latency is less than a few hundred milliseconds.
If your web site is extremely dynamic, it could matter (e.g. if every keystroke in a web browser started from India required an AJAX call to the US-located host).
Read much more about HTTP and perhaps TCP/IP. Don't confuse the World Wide Web with the Internet (which existed before the Web).
If performance really matters to you, you would set up some distributed and load balanced web service, by hosting on each continent. You might for instance use some distributed database technologies for the data (read about database replication), e.g. with PostGreSQL as your back-end database.
Of course, you can find web hosting in India.
And all that has some cost, mostly software development and deployment (network sysadmin skills are rare).
It is a Q & A website.
Then it is not that critical (assuming a small to medium traffic), and you can afford (at first) a single hosting located in a single place. I assume no harm is done if a given answer becomes visible worldwide only after several minutes.
Once your website is popular enough, you would have resources (human labor and computing hosting) to redesign it. AFAIK, StackOverflow started with a single web hosting and later improved to its current state. Design your website with some agile software development mindset: the data (that is past questions and answers typed by human users) is the most important asset, so make sure to design your database schema correctly, taking into account database normalization), and ensure that your data is backed-up correctly and often enough. And web technologies are evolving too (in 2021 the Web won't be exactly the same as today in December 2019, see e.g. this question).
If you wanted a world-wide fault-proof Q & A website, you could get a PhD in designing it well enough. Global distributed database consistency is still a research topic (see e.g. this research report).
I saw in articles that OpenStreet map provides an API that, given a route with an origin and destination and multiple (unlimited?) waypoints it sorts the waypoints according to the best route.
I couldn't tell which endpoint it was. Could someone point me to the part of the documentation that explains how to achieve this? Is there a ruby gem that wraps up this endpoint request?
Thank you very much
This is the traveling salesman problem. There is more than one OSM-based router for solving this problem. According to a similar question at help.openstreetmap.org:
All major OSM routing engines support this:
Mapzen's Valhalla
("Valhalla also includes tools like time+distance matrix computation,
isochrones, elevation sampling, map matching and tour optimization
(Travelling Salesman)."),
Mapbox's
OSRM ("The
trip plugin solves the Traveling Salesman Problem using a greedy
heuristic...")
Graphhopper uses the JSPrit
library
for route optimization ("TSP problem can be modelled by defining a
vehicle routing problem...")
None of these services have a free and unlimited online offering (it
would quickly be abused by people trying to save on their own AWS
cost). Mapzen has an offer where you register a free API key and use
that. OSRM doesn't need an API key, you can just use it. Graphhopper
requires registration and while they have a free trial, I don't think
they have a free tier.
All three are Open Source and you can install and use them without
limits locally.
For GraphHopper take a look at the Route Optimization API. For OSRM see the trip plugin.
Set up your own OpenStreetMap server - this way you won't be incurring data access fees every time your app needs to run maps queries.
Specifically, install the Valhalla maps server. It's a free application. Best to install it on a Linux box:
https://github.com/valhalla/valhalla
Or download and run the docker image in Docker instead:
https://hub.docker.com/r/abihf/valhalla/
https://github.com/interline-io/valhalla-docker
The server provides an API specifically for ordering waypoints:
https://valhalla.readthedocs.io/en/latest/api/optimized/api-reference/
I would like to have a superficial idea about the methods used by Google to perform image annotation and how these methods are related to each other. I couldn't find anywhere else this information, except some user's guesses, and I would like to have something more reliable.
Thank you
I believe much of the API's backend is done with tensorflow. (https://cloud.google.com/blog/big-data/2016/05/explore-the-galaxy-of-images-with-cloud-vision-api, https://cloud.google.com/blog/big-data/2016/02/google-cloud-vision-api-available-to-all)
--> I'm guessing that there's some big ol' deep convolutional neural networks trained from google images, implemented with tensorflow (https://www.tensorflow.org/, http://kaptur.co/what-googles-new-open-source-tensorflow-and-cloud-vision-api-mean-for-photo-app-developers/).
Some tensorflow info about deep convolutional neural networks: https://www.tensorflow.org/versions/r0.9/tutorials/image_recognition/index.html