Forem: jacob moracha

Building a Developer Community from Scratch

jacob moracha — Sun, 13 Apr 2025 21:21:50 +0000

We weren't experienced. Not in community building, not in development. We were just three friends in Mombasa who refused to keep watching from the outside. Everyone we saw doing something in tech belonged to communities we had no access to. Most of the stories we admired came from Nairobi or global circles that felt too far removed from where we were. We were never part of any of that. We didn't get handpicked, we weren't funded, and we didn't even know how things were "supposed" to be done. But we kept seeing what other communities were doing, and something in us said we could do this too. Maybe not bigger, maybe not better, but definitely in our way.
OnlyDevs started with a few more people, but the rest left soon after the idea came up. They liked the sound of it but didn't stick around to build it. It was just the three of us in the end. We didn't even plan much at first. We just said, "Let's do this together instead of alone." And that was it. That's how it started. No structure. No roles. No fancy goals. We were tired of being on the sidelines.

The Early Days

In the early days, I gave everything I had. I stayed up late preparing decks, customizing event platforms, building tools to help us track members, and reaching out to sponsors who mostly ghosted me. I ran the community like a second job but without a paycheck. I did it because I believed in the mission.
We didn't have sponsorships or gear or anything that made us look like a serious group. But we showed up. We found free venues, sometimes begged for space, pulled in speakers, and printed posters from our own pockets. We hosted our events and taught ourselves how to run them on the go. We were building everything from scratch and learning through mistakes.
We poured ourselves into it. After classes. After work. After everything else. We made our own posters, used our own data, and transport money. There were days we didn't know if even five people would show up, but we kept showing up anyway. Because what we were doing felt important.
But even in the mess, people came. Not for the hype, not for the swag, but because they felt something genuine. You could walk into an OnlyDevs event and feel seen. We remembered names. We stayed after the events, talking for hours. We didn't have anything shiny to give, but we gave our time, effort, and presence.

The Impact That Matters

Over time, we started seeing people grow. One guy landed his first internship because of an event we organized. Others went on to lead in their ways. A girl who once sat quietly at the back of one of our sessions is now a full-time developer in Nairobi. Recently, someone stopped me and said, "If it weren't for OnlyDevs, I wouldn't be here." Those moments carry weight. They're reminders that it wasn't all in vain. And that hit me because back then, we didn't know what we were doing, but we knew why we were doing it. And maybe that's exactly why it worked, even if just for a while.

The Hard Truths

Because here's what I learned the hard way: most people don't join communities to build. They come to benefit. They come to take. They're not bad people, just pragmatic. You offer something for free, and they take it. They get what they need, maybe a job referral, a connection, or a spotlight - and then they leave. No goodbye, no thanks, no trace of the hundreds of hours you poured into making that moment possible. It's transactional. You are useful until you're not.
What makes it even harder is when you start seeing others monetize what you built for free. You see people, some of whom grew up in your community, create spin-off brands, monetize events, or land sponsorships using the same concepts you pioneered. No credit, no acknowledgment, just appropriation. And you're left wondering if maybe you gave away too much, too freely.
There were times I would host events and see people attend, then run off and recreate the same format, same guests, same structure, and same resources, but now behind a paywall. It stings. Not because you want control, but because it's a reminder that what you spent months building could be copied in a day. And it's not just the event formats. I've seen people repurpose the same code, the same learning paths, and even the same promotional material and position it as original. And while they rise, you're left patching together the next free thing to give away.

And the emotional toll?

That's something no one quantifies. You build relationships, only to feel used. You watch people you believed in vanish without a trace. You invest emotionally in strangers, hoping that they'll stick around, that they'll give back, that they'll help the next person the way you helped them. Most of the time, they don't. The few who stay? They become your anchors. You treasure them, but they're the exception, not the rule.

The Bigger Wave

Eventually, the wave came. Sponsored communities started popping up everywhere. Not just in Nairobi anymore, but even across Kenya. They were strong. Not because they were bad or fake. No. They had resources. Funding. Support. Consistency. They brought in big names, hosted big events, gave out t-shirts and stickers, and everything else we never had. It wasn't a competition; it was just overwhelming. Their wave was too strong. They created something real, too, but different. They had structure. We had a soul. And maybe that's where the difference lies.
For a while, it seemed like we were living in the shadow of these larger, more structured communities. And truthfully, it was hard to compete. But even more difficult than that was the realization that the deeper, more personal connections we had built were starting to fade. With the big events, the sponsorships, and the flashy giveaways, the focus shifted away from the people. The intimacy we once had began to feel lost.
The connection changes. The feel changes. What we had was handcrafted and human. What came after felt more like a system, smooth and impressive, but distant. We weren't part of that machine. We were three tired friends holding something fragile with our bare hands.
In those sponsored communities, the events became bigger, but the connections became fewer. The systems got smoother, but the individuals felt harder to reach. What we had was more intimate, more personal. But intimacy requires energy. Constant effort. And we were tired. We had our own lives, jobs, and responsibilities. We were never full-time community managers. We just wanted people to have a place to grow together. But over time, giving got harder. Showing up started to feel heavy.

The Silent End

And then, slowly, we stopped.
OnlyDevs didn't end with a statement or announcement. No shutdown tweet. No "thank you for everything" post. It just faded. One event got postponed and then canceled. We stopped replying. Group chats slowed down. The email list gathered dust. The silence grew. And that was it. No one came to take over. No one reached out to revive it. Maybe people assumed we were fine, or that we had moved on to better things. But the truth is, we just couldn't carry it anymore. And no one else offered to carry it with us.
Looking back, I don't think OnlyDevs failed because of competition. It failed because of us. We gave up. Not because we wanted to, but because we were stretched thin and couldn't give what we used to. That's the brutal part. Sometimes, things don't die because they don't matter; they die because the people holding them just get tired. And when no one is willing to step in, the thing you love starts slipping away. We kept hoping someone would take it on, but no one ever did.
I think about that a lot. About how things die quietly when no one cares enough to fix them. About how the people who benefit from a space don't always see what it costs to keep it alive. And about how we don't talk enough about that part. We all love communities when they're vibrant and full. But when they start to break, who's there patching the cracks? We weren't trained for any of this. We didn't even know what we were getting into. But we gave it heart. And when the heart runs out, what's left?

The Lesson

This isn't a call for pity. This isn't bitterness. This is clarity. This is what it really looks like to build a community, not the PR version, not the influencer version, not the sponsored panel version. This is what it's like to build from nothing, to build while everyone is watching and taking not helping.
The culture of community participation has become transactional. Globally, and especially here in Kenya, we've glamorized the idea of community so much that no one talks about what it takes to sustain one. We celebrate the events, the photos, and the vibes, but behind every successful session are tired organizers, often broke, overworked, and wondering if anyone really cares.
The developer ecosystem in Kenya is still young. The coast, especially, is often overlooked. If we don't build our systems, no one will do it for us. But if we're building, let's talk honestly. Let's admit that it's hard, that it's unfair sometimes, that people can be selfish, and that good intentions alone won't save you.
So here's the lesson, the one that still stings when I think about it: building a community is hard. It's about more than passion. It's about resilience, consistency, and the ability to adapt when things get tough. And when you build something from the ground up, you have to know that it won't last forever unless you have people committed to keeping it alive when you can't. That's the brutal truth. And that's what OnlyDevs taught me.

What Remains

Still, I don't regret it. If anything, I'm proud of what we tried. We didn't have much. We had an intention. We had each other. And for a moment, we made something real. Something people still remember. Something people still thank us for. That matters more than any funding or event count.
It's easy to forget the builders when the building crumbles. But we were there. We showed up. We tried. Sometimes that is all you have.
Even if your community doesn't scale, your impact does. People still carry it in how they show up in other spaces, in how they think, and in what they build next.
So, if you're part of a community today, ask yourself who's building it. Who's holding it up when no one's watching? And if you've ever benefited from one, maybe it's time to stop just attending and start giving back. Because the truth is, these spaces don't survive on hype. They survive on people who care enough to keep them alive even when it's hard.
We didn't build OnlyDevs because we were experts. We built it because we were alone, and we didn't want to be anymore. That was it. We refused to wait for someone else to create the space we needed. And even though it ended, I'd do it all again. Not because it worked forever, but because, for a while, it mattered.
OnlyDevs wasn't part of any major ecosystem. We weren't trained, funded, or recognized. But we were present. And we mattered, even if only for a moment.
We built something real.
Not perfect. Not polished. Just real is enough.

Cloud Computing

jacob moracha — Wed, 15 Feb 2023 08:27:04 +0000

What is cloud computing?

The term "cloud computing" has been popular in the IT industry for many years. Cloud computing is rapidly expanding, and many organizations consider it a critical strategy. It has changed the landscape of how businesses operate on a larger scale, providing significant business and technical advantages and benefits that cannot be ignored. In recent years, cloud computing has expanded at an exponential rate. To fully grasp cloud computing, we must first understand some existing technology upon which cloud computing is built.

Virtualization enables the installation of multiple virtual machines (VMs), each running a separate operating system and applications, on a single physical server. The VMs all run concurrently, unaware of each other's existence while sharing the underlying hardware resources. A hypervisor is used to accomplish this.

A hypervisor is a piece of software that allows multiple virtual machines (VMs) to be installed on the same host. It sits between the physical server hardware and the virtual machines. Its role is to create a shared pool of virtual hardware resources that each of them can access. Any request to the hardware is routed through the hypervisor, which then handles the access, ensuring that the hardware resources are shared among all other VMs as configured.

The following are some of the advantages of virtualization:

There is a decrease in capital expenditure. Because less hardware is needed.
Allows you to provision multiple VMs on a single host.
Because there is less hardware, operating costs are reduced.
Your data center requires less space, power, and cooling.
Reduced footprint in your data center because your server hardware takes up less space.

The terms compute resources, storage resources, databases resources, and networks resources are essential for understanding cloud computing. What does each of these mean?

Compute resources

Provide the brains for your workload to be processed. This includes everything needed to process a run request from applications and services.

Storage resources

Merely allow you to keep your data. A storage resource is any resource that allows you to store your data in the cloud.

Database resources

Enable you to store structured sets of data that your applications can use. SQL Server, Oracle, and MySQL are examples of popular database engines.

Network resources

Allow all other resources, such as computing, storage, and databases, to communicate with one another.

So, how do we define Cloud computing?

Cloud computing is a remote virtual pool of on-demand shared resources that provides computing, storage, database, and network services at scale.

Cloud deployment models

Public cloud

A Public Cloud model is one in which a vendor makes available shared infrastructure such as compute, storage, database, and network resources that can be provisioned on demand and typically accessed over the internet for public use. The consumer will not know the exact physical location of their data, but they will be able to specify the geographic region in which it resides to aid with data latency depending on which will provide the best overall performance for them. All backup and maintenance of physical location services such as power calling, as well as physical maintenance of hosts such as hardware failures, will be handled by the Cloud vendor and appear to be invisible to the end user.

Private cloud

A Private Cloud differs from a Public Cloud in that the infrastructure is privately hosted, managed, and owned by the company that uses it, allowing for greater and more direct control over its data. This architecture may be used by businesses that want to keep a tighter grip on security control. As a result, the hardware is typically kept on-site. The same Cloud principles are used in the design, such as virtualization, creating a pool of shared computer storage and network resources, scalability, and on-demand provision. This approach necessitates a larger capital outlay to acquire the host and the physical data center. Furthermore, additional resources, such as operations and maintenance of this equipment, resulting in a higher operational cost than the Public Cloud model.

Hybrid cloud

A hybrid Cloud is a model that combines public and private clouds. This model is suitable for seasonal burst traffic as well as disaster recovery. A hybrid model is established when a network link is configured between the Private Cloud and services in the Public Cloud, effectively extending the Private Cloud's logical internal network.

This combines the advantages of the public and private models and enables you to architect your services in the most appropriate model. However, keep in mind that they share the same drawbacks as both solutions. Hybrid Clouds are typically used for short-term configurations, such as testing and development, and can often serve as a transitional state for enterprises before moving service to a purely cloud-based environment.

Community cloud

The only difference between a community deployment model and a private deployment model is the set of users. Whereas a private cloud server is owned by a single company, a community cloud is shared by several organizations with similar backgrounds.

If all of the participating organizations have the same security, privacy, and performance requirements, this multi-tenant data center architecture can help these businesses improve their efficiency, as in joint projects. A centralized cloud simplifies project planning, management, and execution. All users contribute to the costs. Its advantages include improved security, privacy, and dependability, as well as ease of data sharing and collaboration. Among the shortcomings are, They are expensive when compared to the public deployment model, and they are rarely used. Fixed storage and bandwidth capacity sharing

Key cloud concepts to understand

On-demand resourcing
Essentially, this means that when you want to provision a resource in the cloud, it is almost immediately available for you to allocate where and when you need it. No more waiting for hardware to be ordered, installed, cabled, and configured before using it.

Security
Security is one of the most debated topics in cloud computing, and many businesses are still concerned about its security. However, public cloud vendors such as Amazon Web Services and Microsoft Azure are regarded as more secure than your own data center. This is because they must adhere to global compliance programs across multiple industries and use the shared responsibility model. The vendor will maintain an exceptionally high level of security for the cloud's underlying infrastructure, and it is up to you, the end user, to architect security in the cloud using the tools, services, and applications available.

Scalability
Cloud computing allows you to rapidly scale your environment's resources up and down, as well as in and out, based on the needs and demands of your application and services. Scaling up and down effectively changes the power and performance of an instance, possibly by using one with more CPU or memory power. When you scale in and out, you are simply increasing or decreasing the number of instances in your fleet of compute resources.

Economy of scale
Because of the large scale of resources provided by public cloud options, which are optimized and shared amongst different businesses, you as the end user benefit from incredibly reduced resource costs when compared to traditional hosting.

Flexibility and Elasticity
Cloud computing gives your design approach tremendous flexibility and elasticity. You can have as many or as few resources as you need. You decide how much, how long, and on what scale you want it. Because you have so many options, you can fully customize your environment to exactly how you want and need it, with only the resources you need.

Growth
Provides organizations with the ability to grow by utilizing a diverse set of resources and services. When combined with the on-demand component, your growth constraints are significantly reduced when compared to a traditional on-premises environment. Growth entails being able to easily reach customers by provisioning resources across the cloud vendor's global network.

Utility-based metering
Many cloud services charge you only for what you use. This implies If you only run an instance for two hours and then shut it down, you only pay for two hours' worth of compute resources. You only have to pay for resources when you use them.

Shared infrastructure
Virtualized hosts are used in the cloud. As a result, multiple tenants may have instances running on the same piece of hardware. This significantly reduces the amount of physical hardware required, resulting in less power, cooling, and space in the data center.

Highly Available

Many of the core services provided by the public cloud and its underlying infrastructure are designed to be replicated across different geographic zones and regions. Having data automatically copied to multiple locations allows you to ensure the durability and availability of your data and services without having to configure or architect for this resilience.

Cloud Service Models

There are several cloud-based models we will focus on the main tree models

Software as a service (SaaS)
Software as a service enables the delivery of a widely distributed and accessible application. It is centrally hosted in the cloud, and there is no need to install any software on your local device to use it.

Platform as a service (PasS)
You have more management and control with this service offering because you have access to an application framework that sits on top of the operating system and up. Because the underlying architecture, host hardware, network components, and operating system are typically managed and supported by the vendor, this is an excellent deployment service for developers. allows developers to concentrate on building great new apps on top of the platform.

Infrastructure as a service (IaaS)
It is a model for self-service management of remote data center infrastructures. It provides Internet-based virtualized computing resources. Customization and management at the highest level are provided. as it enables you to architect your portion of the cloud by configuring a virtual network that is separate from other networks and allows you to deploy any resources you require. You can also configure instances starting with the operating system and going up to the installed operating system. Companies purchase IaaS on a consumption model rather than purchasing hardware. Companies can use this model to add, delete, or reconfigure IT infrastructure on the fly. The underlying host, however, is still managed by the vendor for maintenance and security.

Other cloud service models to consider include:

Network as a service (NaaS)
Backup as a service (BaaS)
Database as a service (DBaaS)
Communications as a service (CAAS)
Storage as a service (STaaS)

what is Amazon Relational Database Service (RDS) databases?

jacob moracha — Mon, 26 Sep 2022 07:51:32 +0000

Relational database management systems (RDBMSs) are a core component of many web applications, providing a structured way to store, organize, and access data. Amazon Relational Database Service (Amazon RDS) makes it easy to set up, operate, and scale a relational database in the cloud. Amazon RDS provides you with six familiar database engines to choose from, including Amazon Aurora, MySQL, MariaDB, Oracle, Microsoft SQL Server, and PostgreSQL.

With Amazon RDS, you can deploy scalable relational databases in minutes with cost-efficient and resizable hardware capacity. Amazon RDS automates time-consuming administration tasks such as hardware provisioning, database setup, patching, and backups. Amazon RDS provides you with a choice of database instance types and storage options to fit the performance and cost requirements of your applications. Amazon RDS is available on Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Block Store (Amazon EBS).

Amazon Aurora is a MySQL-compatible relational database engine that combines the speed and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.

MySQL is a fast, reliable, and secure relational database that is trusted by businesses of all sizes around the world.

MariaDB is a community-developed fork of MySQL that is fast, reliable, and secure.

Oracle Database is the world's most popular relational database and is trusted by businesses of all sizes around the world.

Microsoft SQL Server is a relational database management system (RDBMS) from Microsoft.

PostgreSQL is a powerful, open source object-relational database system with an emphasis on extensibility and standards compliance.