Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
I wrote about cypher’s MERGE function a couple of weeks ago, and over the last few days, I’ve been exploring how it works with schema indexes and unique constraints.
There is so much that could be said about the merging of Neo4j and Cypher right now, but it is certainly reasonable to point out that this merger will likely result in many exciting developments in the programming world.
One of the big draws of the O'Reilly Software Architecture Conference was Adrian Cockcroft's talk, "Deliver Faster and Spend Less with Cloud Native Microservices." Cockcroft is an experienced speaker on the conference circuit and he's well-known as the architect who led Netflix into its new era of unprecedented scale and agility.
He now works for Battery Ventures, but he still draws primarily on his experiences at Netflix for his talks. He and his team were the ones behind the greatest success story for the latest trend in software architecture: microservices.
Tight coupling between modules is a bad idea, and the worst form of coupling is cyclic dependencies between modules. Fortunately, there are a few techniques we can use to break the cycles. They are Callback, Escalation, and Demotion, and I’m going to walk through some examples that show each of them in action.
Then, once the dependencies are broken, we’ll look at two more techniques that allow us to invert and eliminate the relationship altogether. The code for each of the samples can be found in the edcie project on my Google code repository. Each example includes a build script and a simple test case. To execute them though, you’ll need GraphViz if you want to use JarAnalyzer. To invoke the build scripts without invoking JarAnalyzer, you can simply type:
A good application lifecycle management (ALM) package has software that is able to carefully manage and monitor all aspects of software development. ALM applications provide tools for managing and completing the phases of design, development, testing, deployment, and ongoing enhancements. With an ALM solution in place, organizations can significantly improve the way they design, build, test, and adapt their software. Greater customer satisfaction, speed of development, and reduction of cost is the often the result.
VersionOne
This article is a continuation of a series of posts about our project named Portfolio Architectures. The previous post, Portfolio Architecture Examples: Healthcare Collection, begins with a project overview, introduction, and examples of tooling and workshops available for the project. You may want to refer back to that post to gain insight into the background of Portfolio Architectures before reading further.
The collection featured today is centered around architectures in the retail industry. There are currently seven architectures in this collection. We'll provide a short overview of each, leaving the in-depth exploration as an exercise for the reader.
If you attend conferences or read technical articles, you could think that microservices are the correct and only way to build a system at the moment.
Despite some pushback from cooler heads, the default architecture is microservices. In this post, I'd like to argue why it's wrong. I'll first get back to the origin of microservices and the fundamental reason to use them. Then, I'll describe why microservices don't fit most organizations' structures. Afterward, I'll move to detail the root problem to solve. I'll conclude by proposing an alternative, less-risky approach.
GraphQL is a popular language, and it’s getting more popular by the day. We hear front-end developers, mobile developers, and back-end developers talking about GraphQL. So it’s clear that developers use GraphQL across the stack. But where exactly does GraphQL fit in the stack, and what benefits do you gain by using it?
In this article, we’ll first do a quick recap of what “the stack” looks like without GraphQL, and then we’ll dive into how adding GraphQL changes it and what that means for building applications.
In the previous two posts in this blog series, we have already covered the system architecture of Milvus, the world's most advanced vector database, and its Python SDK and API.
This post mainly aims to help you understand how data is processed in Milvus by going deep into the Milvus system and examining the interaction between the data processing components.
During the pioneer area of the World Wide Web, the content was static. To serve it, a group of developers created a web server, which is now known as the Apache Web Server.
The Apache Web Server is built around a module architecture. Developers created a module to run CGI scripts to add dynamic content to the lot. Users wrote early CGI scripts in Perl. After a while, it became evident that generating a complete HTML page from scratch was not the best way and that templating - providing an HTML page with placeholders - was a much better approach. The PHP language started like this as a simple templating engine interpreted by a module.
This article is a continuation of a series of posts about our project named Portfolio Architectures. The previous post, Portfolio Architecture Examples: Healthcare Collection, begins with a project overview, introduction, and examples of tooling and workshops available for the project. You may want to refer back to that post to gain insight into the background of Portfolio Architectures before reading further.
The collection featured today is centered around architectures in the telco domain. There are three architectures in this collection and we'll provide a short overview of each, leaving the in-depth exploration as an exercise for the reader.
For a few years now we've been working on a project we have named Portfolio Architectures. These are based on selecting a specific use case we are seeing used in the real world by customers and then finding implementations of that case using three or more products from the Red Hat portfolio.
This basic premise is used as the foundation, but many aspects of open source are included in both the process and the final product we have defined. There is a community, where we share the initial project kickoff with a group of architects and use their initial feedback from the start. We also present the architecture product we've created right at the end before we publish to ensure usability by architects in the field. The final published product includes some internal-only content around the customer projects researched, but most of the content is open and freely available through various open-source channels.
Data Fabric provides a single environment to access data and enable simpler and unified data management by connecting data from disparate sources. Such a data architecture helps businesses to discover unique, business-relevant relationships between the available data points.
Data fabrication is an architecture that is developed to standardize data management practices across multiple environments cloud, on-premises, and edge devices. Data fabric is listed among Gartner’s top 10 Data and Analytics trends. It also allows enterprises to cost-effectively leverage technologies such as artificial intelligence and IoT by reducing time for integration design by 30%, deployment by 30%, and maintenance by 70%. With the increasing scalability and complexity of data from disparate environments in enterprises, a data fabric architecture helps to take the data to the right place and at the right time to make business analysis easy. Thus, it helps to unleash the power of data to meet business demands.
As mentioned previously, I've pushed a few talks to the Devoxx UK 2022 conference being held May 11-13 in London.
The Devoxx series is well known, and I've attended and spoken at multiple sessions for the Belgian version in the past. It's very developer-centric with a lot of good depth and knowledgeable attendees.
Keeping a project competitive within the technology market is, without a doubt, one of the most significant challenges for engineering teams. It is because it is necessary to update and revise solutions constantly: since, in the same way, it is terrible to use legacy technologies, it is also not advisable to use technologies simply because they are buzzwords.
But how to monitor and visualize all these solutions? One way to keep track of these stacks, which are crucial for an organization, is to make your company or teams have a Tech Radar.
When the idea of the Milvus vector database first came to our minds, we wanted to build a data infrastructure that could help people accelerate AI adoptions in their organizations.
With this article on MongoDB to Couchbase comparison, I'm starting a new, detailed series for MongoDB developers to learn Couchbase by comparison. Two years ago, I wrote a single high-level comparative article on MongoDB and Couchbase. I recommend you read that for a bird's view comparison. Both MongoDB and Couchbase have done multiple major releases since then, and developers need a deeper treatment of topics. As developers know, the devil is in the details :-)
This series will be similar to the series for Oracle developers to learn Couchbase by comparison, but for MongoDB developers.
Complex logic should be implemented on data structures you have full control on an internal Domain Model that you can tailor to your problem to simplify your code.
Here is an (opinionated) list of term definitions used in this article: