DEV Community: Greg Lind

Building a Network of AI-Native CTOs

Greg Lind — Wed, 25 Mar 2026 17:01:15 +0000

Over the past few years, I’ve been thinking a lot about how the role of a CTO is evolving—especially with how quickly AI is changing how we build software.

To be honest, I never really liked titles like CEO, CTO, CMO in early-stage startups. They always felt a bit off to me. How can you be the Chief Technology Officer when you’re the only one building?

But I’ve started to look at it differently lately.

Instead of a title, I think of CTO more as a responsibility—especially in smaller, AI-assisted teams. This is not an exclusion of vibe code type prototype founders, just a way to grow beyond that.

The gap I keep running into

Working with early-stage teams, there’s a pattern I keep seeing:

You don’t necessarily need a full-time CTO yet,
but you do need help making good product and technical decisions early on.

At the same time, AI tools are making it easier than ever to build with really small teams.

Which is great—but it also makes it easier to:

Head in the wrong direction
Overbuild too early
Or just lose focus

Speed isn’t the problem anymore. Direction is.

What we’ve been trying

Because of that, we’ve been experimenting with a slightly different approach.

We’re building what we’re calling an AI-Native CTO network through CollabHub.

It’s still early, and we’re figuring it out as we go, but the idea is pretty simple:

Instead of relying on one person to have all the answers,
we try to combine:

Experience
Collaboration (Inside our Community and Out)
Open systems
And AI where it actually helps

A few principles we’re leaning on

Nothing here is groundbreaking on its own, but together it’s been interesting.

1. CTO as a collaborator, not a gatekeeper

I’ve always felt the best technical leadership happens when decisions are shared and visible.

So instead of one person making all the calls, we try to bring in:

Different perspectives
Community input
Real discussion

It usually leads to better outcomes—and fewer blind spots. This contrary to advice I had been giving startups in the past, don't hire a CTO hire a lead developer, but AI has made it easier to hire both in one.

2. AI as an accelerator, not a replacement

We use AI a lot, but mostly for:

Scaffolding
Repetitive work
First drafts

The harder parts—like product thinking, system design, and tradeoffs—still need people.

AI helps you move faster, but it doesn’t decide where you should go. Creative code, decision making and innovation happens when devs are creating it and AI is removing the obstacles.

3. Keeping things open

We’ve been trying to build this in a more open way.

Not just code, but:

How we think about features
How we plan work
How decisions get made

It’s not always the fastest path, but it creates better feedback and learning over time. Using our RAD Process we build in the open first then make things private where it's needed.

4. Learning by doing

We recently started putting together an AI-Native CTO certification, but we didn’t want it to just be another course.

So instead, it’s based on:

Working on real projects
Collaborating with teams
Actually delivering something

We use a lot of guardrails for AI development via pull requests and focus on communication.

What we’re noticing so far

It’s still early, but one thing that keeps coming up:

When teams have even a bit more clarity around:

What they’re building
Why they’re building it
And how they’re approaching it

Things start to move a lot more smoothly.

AI helps with speed, but alignment seems to matter more.

Still figuring it out

We definitely don’t have this all figured out yet.

But it’s been a really interesting direction, and I’m curious how others are thinking about it.

Does the idea of a “CTO” still make sense in small teams?
How are you using AI in your workflow right now?
What’s actually working (or not)?

If you’re exploring similar ideas, I’d genuinely be interested to hear about it.

And if you’re curious about what we’re building, feel free to check out CollabHub—we’re slowly growing a small, open community around this.

THE CRUCIAL ROLE OF HUMAN OVERSIGHT IN ETHICAL AI TESTING

Greg Lind — Fri, 08 Sep 2023 15:21:20 +0000

Artificial Intelligence (AI) has rapidly become an integral part of our lives, powering everything from virtual assistants to decision-making systems. As AI systems continue to advance, the importance of ethical AI development and testing becomes paramount. One key aspect of ensuring ethical AI is the involvement of human oversight in testing, both before and after launch. This is not important just for AI builders, but also those who implement and prompt AI with there own settings and information.

The Ethical AI Challenge

AI algorithms are designed to learn from data and make predictions or decisions based on that data. However, the data used to train these algorithms can sometimes contain biases, leading to unintended consequences. For instance, an AI chatbot may inadvertently respond to users in a biased or discriminatory manner. This can happen from previous training or configuration or based on new data added since deployment or configuration.

To address these issues, ethical AI development as well as implementations require proactive efforts to identify and rectify biases and other ethical concerns. This process begins with rigorous testing.

The Role of Human Oversight

Pre-launch Testing

Before an AI system is deployed, it undergoes extensive testing to ensure it behaves ethically and without bias. Human oversight is vital during this phase for several reasons:

Identifying Biases:
Human testers can identify biases, stereotypes, and inappropriate responses that might have been learned from training data.

Evaluating Cultural Sensitivity:
- Testers from diverse backgrounds assess how the AI responds to different cultural contexts, helping to avoid cultural insensitivity.
Fine-tuning Responses:
- Human oversight allows for fine-tuning responses to ensure they align with ethical standards and community guidelines.

Post-launch Monitoring

Ethical AI development doesn't stop at launch. Continuous monitoring and improvement are necessary. Here's where users come into play:

User Contributions:
- Encourage users to report any problematic AI responses they encounter. Their feedback is invaluable for uncovering issues.
Ongoing Testing:
- Maintain a framework for ongoing testing, involving human oversight, to regularly evaluate AI behavior and responsiveness.

Open Build's Ethical AI Testing Framework

At Buildly and at Open Build, we are committed to advancing ethical AI development in every aspect, from implementation, prompt writing and training. We've developed an open-source Ethical AI Testing Framework that provides a structured approach to testing AI systems for biases and ethical concerns.

Human Testing of Responses

Our framework includes comprehensive test plans for human testing of AI responses, covering various biases like gender, cultural, racial, age, and neurodivergent biases. These test plans involve human testers who assess AI responses for fairness, accuracy, and sensitivity.

User Contributions

We value the input of users in improving AI systems. Users can actively contribute by reporting problematic AI responses, helping us uncover and rectify issues.

Ongoing Testing

Ethical AI development is an ongoing process. With our framework, we emphasize the importance of continuous testing to ensure AI systems evolve in an ethical and unbiased manner.

Join Us in Ethical AI Testing

Ethical AI development is a collective effort. We invite you to join our mission by participating in ethical AI testing and contributing to our open-source framework. Together, we can ensure that AI systems are fair, respectful, and aligned with the values of a diverse society. Please help and review the framework and sign on to help by contributing. Ethical AI Framework from OpenBuild

Visit our Ethical AI Testing Framework to access our testing framework and test plans. Your contributions make a significant impact on the development of responsible and ethical AI.

Let's build a future where AI respects and represents the richness of human diversity.

PSA: A NEW SCAM TARGETING TECH FOUNDERS

Greg Lind — Mon, 13 Mar 2023 23:01:42 +0000

It looks like there is a new scam going around targeting startups and small business. These seem to be well funded scammers, they target innovators with software and deep tech products that aren't funded yet. They steal the identities of small Investment holding companies or angels and use that to target founders with an ID theft scam of their corporate and personal identities that could potentially ruin them.

I did some research and started by looking at a few crowd funding sites that seem to be publishing more information then needed around startup ideas and came across EquityNet. I tested it out and sure enough, after a few weeks I started getting unsolicited emails from so called "investors" who had found us on EquityNet.

So I started checking out these "investors" one by one, first at the domain level on whois.net and getting namecheap.com as a DNS provider for each one, then we ran them through ScamAdvisor. The first "investor" that reached out had a 2/100 rating on Scam Advisor.

Not so good, in fact just about the worst rating possible, though you could argue 1/100 is technically worse, it seems implausible or broken while 2/100 seems legit and just bad. I kept looking, but didn't see anything on the typical reporting sites relating to them scamming startups. They were all foreign holding companies with small investment portfolios, claiming to be looking into US startups based on the current market trends.

All of these "investors" had similar Scam Advisor ratings but no reports. Based on the registry info for each one of them though, we found similarities that pointed to a very obvious scam. Each scam had a similar profile, they found small investment and holding companies without international web presences and created english language websites and email accounts. This essentially allowed them to start up their own shadow investment firms. They used these shadow companies to steal not only money from founders, by way of fake investor insurance policies, but also to document everything about each startup idea, business entity and founder. Then with identities in hand, as well as the business idea associated with the startup they can steal from the founders accounts, fake there identity as well as pitch or sell the idea to real investors either as their own, or masquerading as the startup whose identity they had stolen. Since discovering this we have had a few others come to us with similar stories looking for advise as well as starting to now report it.

If your a founder, or working on project that is looking for funding keep an eye out and vet them thoroughly, and never go for a pay-for-play scheme where they as for a deposit or insurance. More often then not if you just show an investor a SAFE note or something similar, they will let you know if they are legit or not quickly.

I posted the full and original version of this article on for Buildly.

Kubernetes — What Is Cloud Native?

Greg Lind — Thu, 12 Jan 2023 16:27:59 +0000

Kubernetes — What Is Cloud Native?

A lot of what we do at Buildly depends on containers and a way to manage or orchestrate them through Kubernetes. Yes it’s a funny word, greek for helmsman or pilot, but it’s an important open source project that allows developers to build massively scaleable, as well as little itty bitty tiny applications and deploy them almost anywhere.

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

What that means for the rest of us, is that if you build a microservice application, or really any application that has an API and needs to talk to one or more other APIs, Kubernetes can hook that up for you. In it’s most simplest form, it abstracts the server and server configuration or “compute instances” away from your application so you can deploy as few or as many instances of each service as you have more or less traffic hitting your application.

The best part is almost every cloud hosting service now provides a way to manage Kubernetes in their hosting environments. So you can build a service or application with a bunch of containers, like this one here that runs the Buildly Core to help you connect all your services with one authentication layer, and then deploy it do AWS, Google Cloud, Azure or just about any cloud host and it will run and perform just like it does anywhere else.

The Buildly Core, a cloud native Gateway +, acts as a bridge between pre-configured and custom frontend clients and the backend services in a Kubernetes environment. The Buildly core api service provides multiple light weight services, such as a configurable and flexible API gateway (Core), data mesh aggregation service (Mesh) and an authentication and authorization layer (Users). It’s built around a decoupled Microservice architecture pattern but offers more flexibility then most, by giving the developer the option to pick and choose the parts of each Share Nothing, Proxy or Shared Data Microservice pattern they want to use with each independent service.

Originally published atwww.buildly.io/news

Accountability without Blame

Greg Lind — Thu, 29 Dec 2022 20:18:55 +0000

We’ve been thinking a lot about remote teams and management best practices. One of the most difficult to manage is accountability, or more precisely self accountability and making sure everyone knows that mistakes are expected, and self reporting them is a safe thing to do. Searching for someone to blame for an issue just slows us down when we could be searching for a solution.

Often the best way to avoid the blame game, is to be transparent in everything we do. For developers that means checking in code all the time. Everyday, multiple times a day. It shines a light not only on issues you need help with, but how much you can get done in a give day or week. We don’t account by lines of code, but by help given, help asked for and solutions presented. If they work great, if someones else’s worked and you supported them even better.

The point is that accountability is difficult to track even with the best reports, analytics and data. What matters is the productivity of the team, the overall quality and craftsmanship in the code and how much the user appreciates it, even if they can’t see it. Transparency, even radical transparency helps in self accountability as well as quality, but finding solutions rather then seeking who to blame drives the entire team forward.

Successful Product Management in 2022

Greg Lind — Thu, 22 Dec 2022 22:19:59 +0000

In today’s isolated and remote work digital age, product management is more important than ever. Companies need to stay up-to-date with the latest trends and ensure that their products are competitive in the market. But how do you ensure success? Let’s explore the strategies you can use to make sure your product is successful, and differentiate between PROJECT management and PRODUCT management.

What is Product Management?

Product Management is the coordinated management of project and business activities to achieve the end goal or beneficial changes in the project or product. It’s a strategic oversight function responsible for the consistent delivery of initiatives.

The Project Management Institute summarizes it as “A program is a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually. Program management is the application of knowledge, skills, tools and techniques to meet program requirements. Organizations with mature program management are far more successful than those without it, according to our research.”

What it really is though, in very simple terms, for any type of product is the process of:

Designing a Product (Technical and Non Technical Steps)
Developing and Maintaining (For software this means the entire lifecycle not just the start)
Marketing (To internal and External stakeholders)

Whether you apply this to a a new project or want to improve your current process, these are the general steps you need to take.. By using the right tools and techniques, you can be more efficient and effective in managing your products — and therefore be more likely to achieve your goals.

In 2021, Pembroke Consulting conducted an analysis of 2,000 business projects found in the United States. It found that projects that use a professional project management approach are more likely to be successful than those that don’t.

More than half of the projects (54 percent) had issues related to scope, time or cost.”

More than half of the projects (54 percent) had issues related to scope, time or costIn simple terms, if you don’t have the right tools or knowledge, you can’t control your project scope and it will end up being more expensive than if you had used a professional approach. Even if you don’t have the resources to hire a full-time project manager, there are still many benefits to using a professional approach.

Define the Product Goals

Any project or product will inevitably take time and money to complete, so it’s the product manager’s responsibility to ensure the goals of their project are clear and the entire team is aligned with them. This includes understanding how the organization views success, as well as any constraints such as technical limitations, budgetary constraints, or a set release date.

Know Your Audience

In order to achieve project goals, a full understanding of who your audience is will allow you to develop a better sense of what you’re selling to them. While this can be an expansive list — the general public, other

Selling gadgets, applications, digital services, etc. in the digital age requires a comprehensive understanding of product management strategies. With increased competition, having an effective product management plan is essential for success in the marketplace. Understanding how to develop marketing campaigns and use social media effectively can help drive sales and build customer loyalty. Moreover, focusing on research and development for future product lines will ensure that companies stay ahead of the game in a constantly changing digital era.

Product management in the digital age can be daunting, with so many challenges and complex decisions to make. However, there are several strategies which can help product managers to stay on track and ensure success. For example, staying up-to-date with the latest technology trends is essential for success in this field, as well as building a strong understanding of user needs. Additionally, being proactive in anticipating customer needs and doing research around potential future market opportunities can help give you an edge in this fast-moving digital landscape. With these tactics propelling your product management strategy forward you’ll be able to excitedly anticipate what new discoveries await down the road!

Understanding the Basics of Product Management

Product management is a key part of any successful product. It encompasses the development, marketing and maintenance of products throughout their entire life cycle. Meticulous planning and organization are required for product managers to ensure that products are released on time, meet customer expectations and continue to improve over time. Product management enables organizations to stay ahead of the curve, developing innovative products that customers love!

Managing products is an ongoing process that requires a deep understanding of both customer needs and market trends. Only with this insight can you create successful products that meet the demands of your customers and the changing environment they live in. It’s not enough to just understand their wants, you need to have a full grasp on what they need in order to stay ahead of the waves of competition out there. Keeping up with market trends is just as important — if you don’t know what direction your specific industry is taking, it’ll be hard to develop creative solutions that bring success.

Similarly, project management is an important factor in managing products and achieving optimum performance. Product managers must be able to strategize on ways to satisfy the interests of all stakeholders while staying ahead of the competition. By having a well-defined plan and understanding of how the market will react to their product, successful product managers can make sure that their products deliver great results.

Prioritizing Features and Functionality

Identifying the features and functionalities that are most important to your customers is key when it comes to managing products. Utilizing best product management practices will help you prioritize features that provide the greatest value and positively impact your customer base. This is an important step to successfully manage your products and ensure you are meeting the needs of everyone involved.

“Utilizing best product management practices will help you prioritize features that provide the greatest value and positively impact your customer base”

Managing products can be a daunting task, but prioritizing the features and functionalities can help you ensure that the final product is the right fit for your audience. To make this process easier, it’s important to take advantage of tools we use for managing processes, such as software or project management systems. These tools can keep everyone on track and help focus efforts on what will benefit your target audience most.

Designing a Winning User Experience

At the core of every successful product is the concept of designing it with the user in mind. By making sure that users can easily navigate and access features, you’ll be able to create a more enjoyable experience for them, thus contributing to your product’s success. This is why it’s so important to think about what users may want out of your product before creating or managing it. Doing this will allow you to develop something that meets their needs and exceeds expectations.

Leveraging Automation and Technology

Product management is an integral part of any business and managing it can be time-consuming. Fortunately, there are tools we can use to manage processes that help to automate and streamline operations. By freeing up time, this technology allows us to focus on more critical tasks that can have a real impact on our success.

Here is a few PM tools we use to manage processes in Buildly Insight

Trello is a visual project management tool that allows you to organize your ideas and items for a project. It is a very simple way to task-list items and keep track of your progress. Each card can have one task or subtask.

Jira is a leading brand of software applications for project management. Since 2017, it has been home to a number of innovative features, including video calls, data visualizations, and smart project tracking.

GitHub is a popular platform for hosting and sharing code. While primarily a code host, GitHub also provides various tools for managing and distributing files, such as issue tracking, feature requests, and feedback. It’s this last feature that has led to a large number of users. According to GitHub, more than 20 million issues were filed on the site in 2018.

Buildly Insights , we are biased a bit here, but Insights is the only platform designed to help product and development teams work better, faster and easier. We use Insights because it helps translate nontechnical ideas in technical documentation. Insights Release Management helps us plan releases, keep track of progress, and speed up the release and development process. Also at the start of each product cycle, it provides us with an estimated budget, release planning and timeline report. All of this while helping us improve and understand the communication between the product and development teams, to make it feel more like one team.

Implementing Best Practices for Digital Product Management

Having clearly defined roles and responsibilities for product management is essential for a successful organization. Not only does it allow everyone to have an understanding of each other’s job, but it also helps with project management and ensures that tasks are completed in a timely manner. With everyone knowing their individual responsibilities, the team will be able to work together seamlessly and efficiently when managing products.

It’s critical to stay in tune with customer, stakeholder and user feedback when managing projects. This helps us to continuously evaluate our products and make sure we’re providing the best solutions for everyone. Gathering feedback regularly ensures that we can make well-informed decisions about product development and management. With this valuable insight, we can ensure that the product keeps meeting the needs of customers, stakeholders, and users alike.

Meanwhile, it is important to remember to leverage the tools we use to manage processes when it comes to managing digital products. Establishing process for continuous testing, optimization and iteration is essential in making sure customer needs are met. Ultimately, this process helps companies stay competitive in the ever-changing tech industry through effective product management.

Scheduling releases & communication with customers.

Product releases are a critical part of the product development lifecycle. From initial conception to customer delivery, release planning plays an important role in ensuring success. Agile release planning is a methodology that enables teams to plan, track, and deliver high-quality products. In Agile release planning, you prepare for staged releases and then break those down into several different sprints or iterations. It enables teams to become more agile in their release planning by focusing on customer needs and responding to customer feedback.

Effective communication with customers is an integral part of any successful business. Through effective communication, businesses can build relationships with their customers, create a sense of loyalty and trust, and ensure that their customers have a positive experience. Additionally, effective customer service communication can help businesses identify customer needs, provide timely and accurate responses, and build a strong and reliable reputation. By engaging in meaningful dialogue with customers, businesses can create a positive customer experience and establish a loyal customer base. Effective communication with customers is essential to the success of any business, as it helps to build trust, loyalty, and brand recognition.

Wrapping up

In conclusion, effective product management in the digital age requires careful planning, knowledge of the latest trends, and attention to detail. To best achieve success in this ever-evolving industry, use the tips, tricks, and strategies offered in this article as a guide for your product management team. With smart decision-making and an understanding of modern customer needs, using the right PM tools you can ensure that your product will remain up-to-date and competitive in the digital age.

Developing APIs based on OpenAPI Specification

Greg Lind — Thu, 12 Sep 2019 11:33:17 +0000

The universe of APIs is regularly one of competing standards, interests, and arrangements. Standards help give a common framework of communication and development and ground us in picking the correct tools dependent on a particular need.

What is OpenAPI?

I really like the explanation from the OpenAPI website: “The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.”.[1]

Summarizing, the OpenAPI Specification is a solution that produces machine-readable documentation for REST APIs.

Developing APIs based on OpenAPI spec

As Test-driven development (TDD) that combines test-first development where you write a test before you write a solution code to fulfill that test and refactor it, we can also specify endpoints of an API using the OpenAPI framework before starting coding them and refactor. So, prior to beginning to build the business logic of an API, test it, or any other lifecycle, we create the API’s interface, specifying the accurate requests and responses endpoints will display.

Why OpenAPI spec-driven development?

A significant advantage of developing APIs based on OpenAPI specifications is that it enables independence between teams, e.g, Frontend, Backend and QA Engineers know how the API is supposed to do, so they are all aligned on it. Removing these dependencies will also speed up the release process because different teams can do their tasks at a much faster pace.

Another advantage of using this approach is the improvement of Developer experience. Developer experience is about delivering robust functionality that is stable, speedy, and visually intuitive.[2] If you’re thinking about how it can improve the developer experience, you just need to remember that developers will consume your API and having a well defined/documented API will have a great impact on it. You can focus on the API consumer’s needs beforehand.

Conclusion

APIs have evolved beyond a typical backend to frontend pattern. So evolving a standard to help explain an API is more important then ever, which is the reason a consumer-driven perspective on APIs is quickly spreading and the OpenAPI Specification helps us to build APIs while guaranteeing a good developer experience through a definition driven methodology.

Reference:

1 — https://swagger.io/specification/

2 — https://hackernoon.com/developer-experience-dx-devs-are-people-too-6590d6577afe

Microservice Architecture in a Nutshell

Greg Lind — Sun, 08 Sep 2019 16:48:46 +0000

Our team at Buildly have been building applications and getting better at it, most of the time, for years. We have worked with a variety of technologies, architectural patterns, and best practices have been developed along this period. Microservices is an architectural pattern that has emerged during those years, especially because of containers. Docker is the main actor of all these changes because it has popularized containers and helped us containerizing our applications. I thought I might revisit the core concepts of it and the primary pattern and concept we like the most.

Concept

Microservice architecture is a variant of the service-oriented architecture that organizes an application as a collection of loosely coupled services. These services are responsible for specific tasks and can communicate with each other through simple APIs to solve a larger complex business issue. Summarizing, microservices are a particular technique for developing software systems that attempts to concentrate on structuring single-function modules with well-defined interfaces and operations.

Pros & Cons

Microservices are used to speed up development, feature release, ease scalability; they offer improved fault isolation, etc. If you are developing an application and it has to support a variety of different clients including desktop, mobile browsers and native mobile applications, you must consider implementing your application using microservice architecture.

Microservices also bring complexity to network, testing, deploying, monitoring, etc. Team communication can be hard without using automation and Agile methodology. You also might have to introduce CI/CD tool, configuration management, and application-deployment tool, service mesh, and API gateway to help you with testing, building, shipping, discovering and connecting all services.

Conclusion

Along all these years we have improved the way we develop systems and we’ll keep doing it. If you automate and do everything in the right way, you probably won’t face issues and will love microservices. All software architectural patterns and styles have their pros and cons and microservices architecture isn’t different but it helps us to be more agile.

Microservices or just Cloud Native

Greg Lind — Thu, 05 Sep 2019 20:42:13 +0000

A question we have been asking ourselves a lot here at Buildly lately is are we doing microservices or are we just Cloud Native? And is there really a difference? Google seems to have an opinion that microservice architecture is almost required to use a cloud native architecture efficiently. That might be right, but I guess it depends on your definition of “micro”.

I’m certainly a fan of microservice architectures and I think we can all agree that they work best on something like the Google Cloud Platform, but I do have a problem with the term “micro”. Once you get into serverless architectures the term micro, for function driven and stateless architecture certainly fits, but when you need to build a service driven by business requirements and developers need to be able to build those models and relational dependencies as efficiently as possible, maybe micro isn’t the the way you should be thinking.

Maybe these container driven services are more business logic services, or logical services, or something close to that. I have called them logic modules in that past but I’m not sure that explained enough of what they were, certainly module implies modular and reusable, but I think we lose a bit of the right size or proportion that micro would give us.

Certainly reusable services makes sense to us in describing these services, but not every software development process needs to focus on reusability in code. Maybe they should, I know it’s a fundamental I have been taught since I started developing software, but some times businesses have a simple need and a simple monolithic like architecture fits that need much better, even though monolithic may not be entirely accurate in terms of the size of that service either. It’s not easy to argue the value of spending time on reusability to a manger or CEO who is only concerned with building one product. I think the answer here has to be to argue for best practices and standards, to show that smaller more modular bits of code, regardless of reuse, is easier to maintain, optimize and fix when the need arises. This also helps to make code faster to develop by making it easier to spread the workout among different teams and helping to reduce redundancy.

For now, maybe the best thing we can do is to make these terms a bit more synonymous, cloud native and microservice architectures work better together, maybe only work together. If we drop the term micro from the services we are building it doesn’t limit us as much and it gives us the ability to clearly separate these services based on business logic, developer responsibilities and logical functional separation and need for state management. Some have gone back to the Service Oriented Architecture term, and while I have always like that approach it seems like a historically loaded term now and a step back. I always seem to come back to logical services or logic driven services.

Maybe in the end we are bridging some of these gaps between object oriented and functional programming as well, by focusing less on state and more on the structure and execution. Either way it can’t hurt to evaluate these practices to find ways to optimize. In the end these are all just terms, and it’s more about the approach to me, but I guess we need a precise way to communicate it. For now I guess we will stick with logical services, and just explain the difference.

If you’re curious we have put together an introduction on how we mange these services with our gateway functionality with our cloud native services and patterns, and will soon start adding to that with logical separation of services and some ideas on how we can standardize around models.

Cloud Native Patterns

Greg Lind — Thu, 22 Aug 2019 11:07:00 +0000

Buildly is an open source cloud native or microservice gateway and acts as a bridge between pre-configured and custom frontend clients and the backend services. The Buildly core api service provides multiple light weight services such as a configurable and flexible API gateway (Core), data mesh aggregation service (Mesh) and an authentication and authorization layer (Users). It’s built around a decoupled Microservice architecture pattern but offers more flexibility then most, by giving the developer the option to pick and choose the parts of each Share Nothing, Proxy or Shared Data Microservice pattern they want to use with each independent service.

To get a better idea of how this works lets first review a few of the more popular MicroService patterns many developers use and how they can be implemented.

Proxy Design Pattern

The proxy pattern provides a single url endpoint along with basic authentication and authorization across multiple end points. This pattern gives the Frontend or client developers a single URL and endpoint to manage for all data requests. It can also be extended to provide pass-through authentication via a token auth process like JWT that provides basic authentication to each Microservice.

Aggregator Pattern

An extension to the proxy pattern is the aggregation design pattern. This common pattern usually uses a tool like GraphQL at it’s center and allows you to aggregate all or parts of your end point data in one gateway service as a data query tool. This allows for decoupled services while still providing a single URL through a gateway for each service. It’s also provides Frontend developers with one endpoint to query each of the Microservice endpoints as well as perform basic linking or aggregating of the data. In our case we provide a data grid tool that uses Swagger docs to create a simple REST API data mesh for all the related endpoints and allows the developers to pre-configure the desired join queries and cache levels.

Asynchronous design pattern

The Asynchronous design pattern can be used with a gateway or not, but each Microservice can publish data to a messaging queue like RabbitMQ and subscribe to the data it needs from other services. This requires a bit more upfront configuration for each service but provides the needed data and only the needed data to each end point and can help to reduce query time compared to an aggregation service.

Buildly Flexible Pattern

The Flex pattern built into Buildly allows the developers of each LogicModule to choose how they want to share data, either via a messaging Queue or Gateway and API data mesh, or a fully decoupled backend for frontend pattern. The Buildly service provides a simple way to use “workflows” as unique identifiers via UUID’s that are generated in Buildly and that can be registered with the core service and each related LogicModule entry, then used as a lookup service between entries in each backend service endpoint.

Data Mesh

The Flex pattern does not require the developer to subscribe to a particular pattern upfront because all the needed services are running in the Buildly core. This way depending on the use case, type and shape of the data coming into a service developers can choose how to implement each Microservice in the optimal way for that service. The only requirement is that each service provides an OpenAPI swagger doc for each service. This helps ensure a standard style and practice for each API service, but also allows us to aggregate the service where needed into the gateway and data mesh.

These services also allow a developer to create lookup service as join tables for data across Microservices where needed and apply flexible centralized role based permissions for them as well. It gives you the developer a lot of flexibility to design an application the way you want, decouple and part out the work where you want and focus on the building of innovative and flexible applications.

Microservice Flex Patterns

Greg Lind — Thu, 04 Apr 2019 15:58:15 +0000

There are numerous approaches and patterns for microservice architecture. What I'd like to do here is document a few of the more popular loosely coupled architectures and how to combine them into a single more flexible implementation.

To get a better idea of how this works lets first review a few of the more popular MicroService patterns many developers use and how they can be implemented.

Proxy Design pattern as implemented in the Humanitec BiFrost core.

Aggregator Design pattern as implemented with the Humanitec BiFrost core

Asynchronous Design patter as implemented in Humanitec’s BiFrost core.

Humanitec BiFrost Flex Pattern

A Microservice Flex Service plattern (a term we came up with at Humanitec after building it into our Walhall platform) allows the developers of each service to choose how they want to share data, either via a messaging Queue or Gateway and API data aggregation, or a fully decoupled backend for frontend pattern. An example is our BiFrost service that provides a simple way to use “workflows” as unique identifiers via UUID’s that are generated in BiFrost models and that can be registered with the core service and each related service entry, then used as a lookup table/service between entries in each backend service endpoint.

BiFrost and the data mesh

The Flex pattern does not require the developer to subscribe to a particular pattern upfront because all the needed services are running in the BiFrost core. This way depending on the use case, type and shape of the data coming into a service developers can choose how to implement each microservice in the optimal way for that service. The only requirement is that each service provides an OpenAPI swagger doc for each service. This helps ensure a standard style and practice for each API service, but also allows us to aggregate the service where needed into the gateway and data mesh.

Originally published at humanitec.com.

Building Sustainable Open Source Communities

Greg Lind — Wed, 21 Nov 2018 15:56:58 +0000

An evolving relationship with open source

When I first started working with NGO’s and government agencies, I don’t think I fully realized how lucky I was to be at an organization building enterprise software, that was supportive at any level of open source. It wasn’t a perfect relationship by any means, but they could see the value in distributing the work load, getting more than one set of eyes on a problem and not needing to reinvent the wheel. However, when the code started to include a business process or a tool for doing their work better, they quickly became more concerned about competitive advantages or liability then building something with a community. I found that more than a little ironic, since most NGO’s and governments have community representation and build or rebuild communities as part of their core mission, but I could see their point for the most part.

Open source wasn’t, and maybe still isn’t, totally about community building, as much as it is about sharing, getting feedback (hopefully constructive) and making a new tool or an existing one better. The community is an afterthought in most cases, and sustaining and growing it comes well after that. Some of it is just in the way the rules and process have grown organically around open source, and some of it is maybe due to keeping parts of the control to ourselves, as developers, and only letting the “worthy” in to participate.

Maybe in some cases it’s okay to build in isolation and focus on your idea alone, I don’t know. But I do know that the projects I use the most tend to have inclusive and large communities built around them, as well as some minimal way for the maintainers and contributors to sustain themselves from it.

Why Open Source is important

There are a number of ways being open is important to some projects and people. To me, though, the biggest benefit I see is that the best ideas, the most transparent processes, tend to win out, and that almost always ends up driving the creation of the best tools.

A few years ago when I helped build a project management system for an NGO, I wasn’t thinking “how will this best benefit just this one NGO?” I was thinking “who else could benefit from this?” or “how can we standardize the industry around a tool or data format?” and “what can we learn from a huge user base using this for many different projects and share that information with each other?” I knew that open sourcing that project and getting other agencies involved was the best way to ensure it was sustainable. Beyond that though, I knew that Projects and Project Management are universal to almost every field, and it wasn’t a stretch to see that other companies in differing industries might be interested in seeing or adapting some of the practices NGO’s were refining in this tool. From years of globally distributed workforces, KPI management, and working in complex or challenging political environments NGO’s have to work harder and more efficiently then most for-profit companies or government agency and they end up with some unique takes on typical processes.

Building a community and getting consensus on tool and processes in these types of organisations is hard work though. Everyone has a slightly different variation on a process or naming convention and little time during a crisis to talk out the differences, meaning customisation would rule over standardisation. Without the funding for the project long term and the will to invest in it, the project would begin to slowly die in the organisation. It led us, though, to the kernel of an idea around a platform for building these types of tools. Reusable and scaleable, but with simple customisation options, but with a solid financial incentive for contributing, and a way to sustain it in the long run.

Sharing Economies

Open source, as it is defined now, is also to a certain extent about complete openness. There is some room for interpretation, but in the end, by the current accepted definition, transparency doesn’t matter unless anyone can take it and do almost whatever they want with it.

This is where we have tried to adjust the model and maybe definition a bit. We want to build a new category of license for future platforms that remove the limitations against selling or reselling a version of open source software by simply adding the requirement to share the compensation one would gain from using the work of others. It also will allow room for a type of Open that is more about the code and sharing and learning, while pushing innovation without removing the ability to resell and earn a living.

In the end this sort of a license structure will allow us all to benefit from making a product or tool better, but financially and in a way that doesn’t require a donation. In this process, we can build communities around these tools that can be sustained through financial and quality advancements. Yes, some of the old guidelines and rules need to still be in place for contribution, but in the end, the community will vote on what contribution is best by using the best tool.

Intellectual Property

New licenses and new models. You own what you build and you can share it, sell it and distribute it on our platform. It’s really as simple as that. You can decide to share it and get more developers involved, or you can keep all to yourself. What matters, though, is that it’s open. If I want to use it or connect to it, I can see the code, I can see how it was built, and I know how to interact with it if I want to combine it with something else. I can even help you debug it or enhance it if you want, or suggest a library that might be better or faster. Either way, it’s still open source, just with a slightly better model for you to make a living off of it.

We really see this as a way to keep the spirit of open source, both your personal and our maybe more general definition of it, with a license and IP model that is focused on building these sustainable communities and tools for enterprise software development. This way we reduce the dependency on large corporate organizations to fund open source projects, and then eventually control them, but rather independent developers or organizations who can work together to solve a problem and share it while still retaining a financial stake in their hard work.

What you have instead of a completely open and shareable project is a transparent and open code base along with a way to build together as a community, share credit where it is due and build financial and project sustainability. It’s not against the standard definition of open source but more of a subset that allows a new business model to evolve while keeping with the spirit of the original.

If you curious we have an open source project for our Angular front end framework with the license in it here: https://github.com/Humanitec/midgard-angular/blob/master/LICENSE

Yes it's based on the Affero GPL license which has some of it's own historical hangups but the adaptation we have made makes it fit our new Commerce Open Source definition. Take a look, keep an open mind and tell us what you think.