In a recent blog post, we discussed object-inspired container design patterns in detail and the sidecar pattern was one of them. In a sidecar pattern, the functionality of the main container is extended or enhanced by a sidecar container without strong coupling between two. This pattern is particularly useful when using Kubernetes as container orchestration platform. Kubernetes uses Pods. A Pod is composed of one or more application containers.

In a recent article, Lake et al. ¹ examine what it means for a machine to learn or think like a person. They argue that contemporary AI techniques are not biologically plausible hence not scalable to the extent that will enable a machine to learn or think like a person. For instance, most neural networks use some form of gradient-based (e.g., backpropagation) or Hebbian learning.

The idea of Bloom Filter was conceived by Burton H. Bloom in 1970. In a nutshell, Bloom filter is a space-efficient probabilistic data structure normally used to check for set membership (i.e. Is element x in set S? ). Bloom filter offers incredible memory and run-time savings for set membership queries with a small margin of error i.e. false positives.

Computer science is full of complex hard-to-understand algorithms. Understandability of an algorithm - ability to explain an algorithm in simple terms - is generally under appreciated. Often poor understandability of an algorithm has a direct impact on practical real-world applications. In my opinion, if we can’t develop intuitions about algorithm it will be very difficult to implement or extend the algorithm for real-world use cases.

If we start thinking containers in terms of objects, it abstracts away the low-level details but reveals higher-level patterns that are common to a variety of applications and algorithms. A recent paper, published by Google Researchers Brendan Burns and David Oppenheimer, suggests that containers are particularly well-suited as the fundamental “object” in distributed systems by virtue of the walls they erect at the container boundary .

Setting and running Kubernetes on Amazon Web Services (AWS) is a very involved process. AWS has decided to not implement Kubernetes as a Service but built something of its own - Amazon EC2 Container Service (ECS). Hence, you need to know and consider a lot of things before you can successfully roll out Kubernetes on AWS. These are the consideration which can make or break it your Kubernetes rollout.

Function as a Service (FaaS) remains at the core of the serverless movement. That said, most of practical serverless implementations I have seen use a combination of serverless functions and more conventional microservices running in containers. Instead of a one-size-fits-all approach, i.e. trying to use serverless function for everything, a balanced approach is highly recommended.

Functions as a service (FaaS) is an emerging pattern to build APIs and microservices at scale. You can use various FaaS implementations such as AWS Lambda, Azure Functions, and Google Cloud Functions to build APIs ecosystem for your organisation. If you remove serverless requirements, stored procedures can be considered as a variation of FaaS because they share similar traits and concerns.

Implementing agile which works and delivers can be a very challenging task, especially in corporate and enterprise environment. According to 10th State of Agile Survey, two of the top five causes of failure were related to company culture – company philosophy or culture at odds with core agile values. A good company culture means a resilient workforce and overall better business performance.

To unlock the true value of data, organisations will need internal data services. Data services provide streamlined and centralised data access to a diverse set of users which removes the friction in delivering faster insights, products and services. Data services promote innovation. In addition, effective implementation of data services can reduce data duplication hence reducing the cost of data management and storage.

When using Amazon Redshift, distribution style plays an important role in optimising the table design for best performance. In a nutshell, table’s distribution style dictates how the data is distributed across Redshift node and slices. A key objective is to avoid the data redistribution during query execution or runtime. This is accomplished by locating or co-locating the data where it needs to be before the query is executed.