To force the cultural change, Infrastructure and DevOps teams might be trying their best to serve the developer, but walking a mile in someone else’s shoes isn’t easy even with the best of intent. Consider cross-pollinating the teams, rotating a few individuals every so often, as the permanent state. That way, those creating the developer experience will have to experience it themselves, which tends to blow up any feeling of pride in one’s creation. In the opposite direction, the application developer gets to explain the problems inside the DevOps team in a much more effective way than in a series of meetings. Above all, the tactic helps the overall culture of collaboration in a more effective way than I’ve seen result from any insistence by management that “we’re one team”. Furthermore, application developers crave understanding what they are trying to accomplish and problem solving in light of it. A happy developer is one who works directly with business people who define the goals, use creativity to solve them, and experience the results. An unhappy developer is one who builds something dictated without understanding why, and never finds out if it worked.
Ultimately, the advantage of microservices is that it decouples development, it reduces developmental coupling so that teams can make progress more independently of one another. Otherwise, it's just a service oriented architecture. It's not microservices. That decoupling is important. One of the things that I like in most definitions of microservices is that people say they should be aligned with a bounded context. That makes sense to me. I was chatting with Eric Evans about this a couple of weeks ago, and he came up with an idea that resonated with me, which is that the messaging layer is a separate bounded context. I think multiple separate bounded contexts. You have the bounds of the service, and then the messaging is something else. The protocol of exchanging information between the services is another abstraction. One of the things that resonates with me, another thing from Eric's book, is that you always translate when you're crossing bounded context. We should be translating the messages as they go across. Then that makes the example that Holly came up with an easier problem to deal with, where we have these ideas that are sometimes the same and sometimes different and sometimes related.
Eternity—which researchers discovered on a TOR website, where the malware-as-a-service also is for sale—demonstrates the “significant increase in cybercrime through Telegram channels and cybercrime forums,” researchers wrote in the post. This is likely because threat actors can sell their products without any regulation, they said. Each module is sold individually and has different functionality that researchers suspect is being repurposed from code in an existing Github repository, which project developers are then modifying and selling under a new name, according to Cyble. “Our analysis also indicated that the Jester Stealer could also be rebranded from this particular Github project which indicates some links between the two threat actors,” they wrote. ... Threat actors are selling the Eternity Worm, a virus that spreads through infected machines via files and networks, for $390. Features of the worm include its ability to spread through the following: USB Drives, local network shares, various local files, cloud drives such as GoogleDrive or DropBox, and others. It also can send worm-infected messages to people’s Discord and Telegram channels and friends, researchers said.
There are three rules of thumb that seem to be evolving. First is that companies that get the most value from this actually spend a lot of effort thinking about, “What are the new digital businesses to launch? How can we create new value with new products and new customers versus transforming the existing business processes?” There’s sort of a duality—you should spend as much focus on new digital business building as you do on transforming the current business. Rule of thumb number two is, you’ve got to focus on things that are big enough. And maybe that’s obvious, but it sometimes surprises us how many people will call something a digital transformation, and you add up the total economic impact, and it’s less than, say, 15 or 20 percent of the company’s overall EBITDA. If you’re not targeting at least 15 or 20 percent, in our mind it’s hard to call that a transformation and to sustain the level of organizational focus around it. And then the third rule of thumb is, it’s best to start with a concentration in a particular area rather than sprinkle a little bit of digital or a handful of analytics use cases broadly across the organization.
Micronaut delivers a slew of benefits gleaned from older frameworks like Spring and Grails. It is billed as "natively cloud native," meaning that it was built from the ground up for cloud environments. Its cloud-native capabilities include environment detection, service discovery, and distributed tracing. Micronaut also delivers a new inversion-of-control (IoC) container, which uses ahead-of-time (AoT) compilation for faster startup. AoT compilation means the startup time doesn't increase with the size of the codebase. That's especially crucial for serverless and container-based deployments, where nodes are often shut down and spun up in response to demand. Micronaut is a polyglot JVM framework, currently supporting Java, Groovy, and Kotlin, with Scala support underway. ... One cloud-native concept that Micronaut supports is the federation. The idea of a federation is that several smaller applications share the same settings and can be deployed in tandem. If that sounds an awful lot like a microservices architecture, you are right. The purpose is to make microservice development simpler and keep it manageable. See Micronaut's documentation for more about federated services.
In the past, most authorization decisions have happened at the gateway — and developers can still enforce authorization there for microservices, if they like. However, for security, performance and availability, it’s typically preferable to also enforce authorization steps for each microservice API. As mentioned, in a zero-rust architecture, every request must be both authenticated and authorized before it is allowed. It’s entirely possible to send each of these authorization requests to a centralized service. However, this can add significantly to latency — for instance, a single user request might traverse numerous services, and if each of those requests requires an additional network hop to reach that centralized authorization engine, that can hamper the user experience. If you’re using a tool like OPA, fortunately, you can also run a local authorization engine and policy library as a sidecar to each microservice. Here is an example of what this architecture looks like with an Istio service mesh, which uses an Envoy proxy sidecar. Using this model, you can ensure that each request passes muster with an authorization check while maximizing the performance and availability of the service.
"Today boards say, 'Can you come and brief our board, and can you stay while the CISO's briefing the board? And can you please give us a view about the quality of our controls and our estimation of risk?', which is hugely transparent," she said, speaking at the UK National Cyber Security Centre's (NCSC) Cyber UK conference in Newport, Wales. "I see that as well, it feels as if it's really maturing," said Lindy Cameron, CEO of the NCSC. "We've been trying really hard over the last few months to get organisations to step up but not panic, do the things we've asked them to for a long time and take it more seriously". The NCSC regularly issues advice to organisations on how to improve and manage cybersecurity issues, ranging from ransomware threats to potential nation state-backed cyberattacks – and Cameron said she's seen a more hands-on approach to cybersecurity from business leaders in recent months. "I've seen chief execs really asking their CISOs the right questions, rather than leaving them to it because they don't have to understand complex technology. It does feel like a much more engaging strategic conversation," she said.
The methodology and insights from the top techniques list has many practical applications, including helping prioritize activities during triage. As it’s applied to more real-world scenarios, we can identify areas of focus and continue to improve our coverage on these TTPs and behaviors of prevalent threat actors. Refining the criteria can further increase results accuracy and make this project more customer-focused and more relevant for their immediate action. ... This collaboration and innovation benefits everyone in the security community, not only those who use the MITRE ATT&CK framework as part of their products and services, but also our valued ecosystem of partners who build services on top of our platform to meet the unique needs of every organization, to advance threat-informed defense in the public interest. Microsoft is a research sponsor at the Center for Threat-Informed Defense, partnering to advance the state of the art in threat-informed defense in the public interest. One of our core principles at Microsoft is security for all, and we will continue to partner with MITRE and the broader community to collaborate on projects like this and share insights and intelligence.
Traditional organizational architecture can impose limitations on an enterprise’s ability to successfully reach its digital transformation goals. The up-front model, with a focus on one long-range project, can slow productivity and choke creativity. While planning is needed as agility scales, the detailed technology life cycles with large timeline projections are no longer effective or profitable in meeting the business mandates that drive enterprises forward. Enterprise leaders are increasingly abandoning the five-year architectural plan for one that is designed to evolve with the ever-changing software development environment. Enterprise architects must now develop and promote adaptive methods that support agility in order to appropriate the value of new technologies like AI, machine learning, big data, IoT and intuitive tools that enable advanced analytics and enterprise-wide collaboration. A less intentional architecture, decomposed into smaller units, can be managed by autonomous cross-functional teams that are accountable to peers and managers with shared strategic objectives, bringing all fields into a coherent whole.
We're starting to use CICD as a noun rather than a verb and we think it's something that we can buy and then put on the shelf and then we have CICD. But if we sort of think about the words in CICD it's continuous integration and continuous delivery or deployment, confusingly. And so what I often see is I'll see teams where they're using feature branches and they'll integrate their feature branch once a week. So that of course is not continuous integration. It's better than every six months, but it's fundamentally not continuous. And really, I think if you're doing continuous integration, which you should be, everybody should be aiming to integrate at least once a day. And that does mean that you have to have some different habits in terms of your code, you sort of need to start coding with the things that aren't visible and then go on to the things that are visible and other things like that. You need to make sure that your quality's in place so that you've got the tests in place first so that you don't accidentally deliver something terrible.
Quote for the day:
"Leaders know the importance of having someone in their lives who will unfailingly and fearlessly tell them the truth." -- Warren G. Bennis