Microservices should simplify software development. In theory, we can stitch microservices together with a top layer, assembling applications out of components. The promise isn’t new, but it is worth examining.

Ivar Jacobson proposed the idea of software components, like circuit-board components, in 1967. He wanted to make building software more like assembling prefabricated blocks of code and less like creating everything from scratch. Yet, something happens every time we get close to Jacobson’s component dream. The components require new layers of complexity. In microservices, this means additional programming to ensure uptime, reliability and observability. We aim for easy-to-assemble building blocks, but end up with a great deal of code in reality.

One emerging alternative that knocks out the microservices complexity problem is low-code development, a way to turn actions and data into applications with minimal conventional programming. In some ways, microservices and low-code development solve similar problems. Low-code development platforms emerged as a way to build apps with out-of-the-box, standardized components, using prebuilt templates. Low-code does not provide the development sophistication of microservices. It can, however, work in situations where managing microservices leads to more effort than the benefit promised by that architecture.

Once software developers and architects understand these microservices complexity issues, they can determine how and when low-code development platforms provide a viable workaround.

Microservices’ code, resiliency and uptime problems
Microservices independently communicate with one another over internet standards, which is what makes the architecture powerful. Because they speak TCP/IP and deliver data payloads in JSON, the components can fit into each other without dependencies. These small services each perform one task well. A company can have a set of services for customer information, another for product lookup, a third for orders and a fourth for delivery.

But breaking things down along business functions means there’s a lot of code to manage. When something goes wrong, there may be an entire chain of events to debug. Microservices requires logging and monitoring work that exists outside the idea of simple components, and creates an explosion of code.

When something goes wrong, figuring out which component contributed to the issue can be tricky without the right tools — which, again, means more code. While each service has high uptime in this supported deployment, resilience and reliability at the code level start to crumble.

The alternative in low-code
With low-code development, the platform builds and delivers the building blocks for an application.

The developers, or even business unit representatives, provide the variables, database connection, formatting and styling, and the tool generates the application, sometimes via a drag-and-drop UI. Provide the data, and a low-code development platform can even build a database. This is, in effect, the opposite approach to microservices, where you provide the database, abstract it into a service, and code the service logic.

Low-code development platforms generally reuse a great deal of common code. There is a massive reduction in lines of code, perhaps even hundreds to one. There are also fewer independent components, which are tightly coupled to each other. Each line of code becomes more powerful and traceable.

The simple example of a low-code development platform might be a database with a Create, Read, Update andDelete (CRUD) front end. A programmer can sketch out the table visually and fill in data through a simple spreadsheet. Users can access the data through the CRUD front end, which lives in an application that the platform generates, and can be downloaded from an app store.

A low-code platform does nearly everything that conventionally is coded for an application; most of the work for adopters is in tool configuration. As long as the app is simple, clean and doesn’t require many integration points, a low-code development platform might be the right alternative to a more complex microservices build. Low-code builds are an easy choice for applications that don’t need to integrate with other databases or that use a series of small tables. Examples include conference apps or one-time marketing promotions that run with user ID information.

Low-code development does not replace microservices. Once you need to share information between applications, in real time, microservices become the right strategy. But the low-code approach helps developers steer clear of over-engineering apps that don’t need it.

The post Low-code development combats microservices complexity appeared first on Artificial Intelligence.

Apple has struggled in recent years to establish a robust artificial intelligence (A.I.) practice. This partially stems from the company’s ironclad privacy policies—it’s more difficult to analyze datasets for insights when internal rules prevent the company from using every piece of user data it can vacuum up. Nonetheless, Apple’s newest projects show that it’s powering ahead anyway—including one platform that, if it’s ever released, could change how you use A.I. and machine learning (ML).

(It’s worth remembering how, in a 2015 speech, Apple CEO Tim Cook accused tech giants such as Facebook and Google of “gobbling up everything they can learn about you and trying to monetize it,” which he framed as “wrong.” It seems unlikely that Apple’s stance on data and privacy will change during Cook’s tenure.)

According to a just-released paper with the dry-but-mysteriously-compelling title “Overton: A Data System for Monitoring and Improving Machine Learned Products,” a group of Apple researchers describe their work on a machine-learning platform (named—you guessed it—“Overton”) designed to “support engineers in building, monitoring, and improving production machine learning systems.”

How does Overton go about this herculean task? By automating the nitty-gritty of machine-learning model construction, deployment, and monitoring. Apple claims that the platform is already in use, supporting multiple initiatives “in both near-real-time applications and back-of-house processing.” These Overton-powered applications have “answered billions of queries in multiple languages and processed trillions of records reducing errors 1.7 – 2.9x versus production systems.”

This means that any researcher or engineer working with Overton will need to trust that the platform can recognize and fix issues with a model; otherwise they’ll presumably need to dig into the algorithms and datasets themselves, a lengthy and stressful process. But if it truly works as it says on the proverbial tin, it should reduce the time necessary to churn out results. Here’s an except from the paper on what the model inputs:

Overton takes as input a schema whose design goal is to support rich applications from modeling to automatic deployment. In more detail, the schema has two elements: (1) data payloads similar to a relational schema, which describe the input data, and (2) model tasks, which describe the tasks that need to be accomplished. The schema defines the input, output, and coarse-grained data flow of a deep learning model. Informally, the schema defines what the model computes but not how the model computes it: Overton does not prescribe architectural details of the underlying model (e.g., Overton is free to embed sentences using an LSTM or a Transformer) or hyperparameters, like hidden state size.

And this is what Overton does with that schema/input:

Given a schema and a data file, Overton is responsible to instantiate and train a model, combine supervision, select the model’s hyperparameters, and produce a production-ready binary. Overton compiles the schema into a (parameterized) TensorFlow or PyTorch program, and performs an architecture and hyperparameter search. A benefit of this compilation approach is that Overton can use standard toolkits to monitor training (TensorBoard equivalents) and to meet service-level agreements (Profilers). The models and metadata are written to an S3-like data store that is accessible from the production infrastructure. This has enabled model retraining and deployment to be nearly automatic, allowing teams to ship products more quickly.

So Overton is going to reduce the amount of coding that machine-learning researchers and data scientists need to do—allowing them to observe and manage the process from a higher level. Plus, it’s interoperable with platforms such as Google’s TensorFlow, which are becoming industry-standard.

Apple isn’t unique in producing a tool that attempts to take as much of the coding grind out of the machine-learning process as possible. For example, Google has AutoML, which is similarly designed to produce working machine-learning models with a minimum of code; there’s also Microsoft’s Machine Learning Studio, which attempts to boil down ML model building to a drag-and-drop process. Automating ML and A.I. is key to these technologies going as mainstream as possible.

The revelation of Overton is also interesting, as it shows that Apple’s researchers are moving on parallel tracks to other tech firms. Apple’s tool might help its internal staffers catch up to their rivals in A.I./ML, but it’s an open question whether they’ll ever transform it into a public-facing product, just as they’ve done for CoreML and other tools.

The post Apple ‘Overton’: Automating Low-Code Machine Learning appeared first on Artificial Intelligence.